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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The present document defines the principal purpose and use of International Mobile station Equipment Identities (IMEI) 
within the digital cellular telecommunications system and the 3GPP system. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document defines the principal purpose and use of International Mobile station Equipment Identities (IMEI) 
within the digital cellular telecommunications system and the 3GPP system. 

The present document defines: 

a) an identification plan for mobile subscribers in the GSM system; 

b) principles of assigning telephone and ISDN numbers to MSs in the country of registration of the MS; 

c) principles of assigning Mobile Station (MS) roaming numbers to visiting MSs; 

d) an identification plan for location areas, routing areas, and base stations in the GSM system; 

e) an identification plan for MSCs, SGSNs, GGSNs, and location registers in the GSM system; 

f) principles of assigning international mobile equipment identities; 

g) principles of assigning zones for regional subscription; 

h) an identification plan for groups of subscribers to the Voice Group Call Service (VGCS) and to the Voice 
Broadcast Service (VBS); and identification plan for voice group calls and voice broadcast calls; an 
identification plan for group call areas; 

i) principles for assigning Packet Data Protocol (PDP) addresses to mobile stations; 

j) an identification plan for point-to-multipoint data transmission groups; 

k) an identification plan for CN domain, RNC and service area in the UTRAN system. 

1) an identification plan for mobile subscribers in the WLAN system. 

m) addressing and identification for IMS Service Continuity 

n) an identification plan together with principles of assignment and mapping of identities for the Evolved Packet 

System 

1.1 References 

1.1.1 Normative references 

The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 21.905: "Vocabulary for 3GPP Specifications ". 

[2] 3GPP TS 23 .008 : "Organization of subscriber data" . 

[3] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2" 

[4] 3GPP TS 23.070: "Routeing of calls to/from Public Data Networks (PDN)". 
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[5] 3GPP TS 24.008: "Mobile Radio Interface Layer 3 specification; Core Network Protocols; Stage 

3". 

[6] 3GPP TS 29.060: "GPRS Tunnelling protocol (GTP) across the Gn and Gp interface". 

[7] 3GPP TS 43.020: "Digital cellular telecommunications system (Phase 2+); Security related 

network functions". 

[8] void 

[9] 3GPP TS 5 1 .0 1 1 : " Specification of the Subscriber Identity Module - Mobile Equipment (SIM - 

ME) interface". 

[10] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[11] ITU-T Recommendation E.212: "The international identification plan for mobile terminals and 

mobile users". 

[12] ITU-T Recommendation E.213: "Telephone and ISDN numbering plan for land Mobile Stations in 

public land mobile networks (PLMN)". 

[13] ITU-T Recommendation X.121: "International numbering plan for public data networks". 

[14] IETF RFC 791: "Internet Protocol". 

[15] IETF RFC 2373: "IP Version 6 Addressing Architecture". 

[16] 3GPP TS 25.401: "UTRAN Overall Description". 

[17] 3GPP TS 25.413: "UTRAN lu Interface RANAP Signalling". 

[18] IETF RFC 2181: "Clarifications to the DNS Specification". 

[19] IETF RFC 1035: "Domain Names - Implementation and Specification". 

[20] IETF RFC 1 123: "Requirements for Internet Hosts — Application and Support". 

[21] IETF RFC 2462: "IPv6 Stateless Address Autoconfiguration". 

[22] IETF RFC 3041: "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". 

[23] 3GPP TS 23.236: "Intra Domain Connection of RAN Nodes to Multiple CN Nodes". 

[24] 3GPP TS 23.228: "IP Multimedia (IM) Subsystem - Stage 2" 

[25] Void 

[26] IETF RFC 3261: "SIP: Session Initiation Protocol" 

[27] 3GPP TS 3 1 . 1 02: "Characteristics of the USIM Application. " 

[28] Void 

[29] 3GPP TS 44. 1 1 8 : "Radio Resource Control (RRC) Protocol, lu Mode" . 

[30] 3GPP TS 23.073: "Support of Localised Service Area (SoLSA); Stage 2" 

[31] 3GPP TS 29.002: "Mobile Application Part (MAP) specification" 

[32] 3GPP TS 22.016: "International Mobile Equipment Identities (IMEI)" 

[33] Void 

[34] Void 

[35] 3GPP TS 45.056: "CTS-FP Radio Sub-system" 

[36] 3GPP TS 42.009: "Security aspects" [currently not being raised to rel-5 - Pete H. looking into it] 
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[37] 3GPP TS 25.423: "UTRAN lur interface RNSAP signalling" 

[38] 3GPP TS 25.419: "UTRAN lu-BC interface: Service Area Broadcast Protocol (SABP)" 

[39] 3GPP TS 25.410: "UTRAN lu Interface: General Aspects and Principles" 

[40] ISO/IEC 7812: "Identification cards - Numbering system and registration procedure for issuer 

identifiers" 

[41] Void 

[42] 3GPP TS 33.102 "3G security; Security architecture" 

[43] 3GPP TS 43.130: "lur-g interface; Stage 2" 

[45] IETF RFC 3966: "The tel URI for Telephone Numbers" 

[46] 3GPP TS 44.068: "Group Call Control (GCC) protocol". 

[47] 3GPP TS 44.069: "Broadcast Call Control (BCC) Protocol ". 

[48] 3GPP TS 24.234: "3GPP System to WLAN Interworking; UE to Network protocols; Stage 3". 

[49] Void 

[50] IETF RFC 4187: "EAP AKA Authentication". 

[51] IETF RFC 4186: "EAP SIM Authentication". 

[52] 3GPP TS 23.246: "Multimedia Broadcast/Multicast Service (MBMS); Architecture and functional 

description" 

[53] IETF RFC 4282: "The Network Access Identifier". 

[54] IETF RFC 2279: "UTF-8, a transformation format of ISO 1 0646" . 

[55] 3GPP TS 33.234: "Wireless Local Area Network (WLAN) interworking security". 

[56] Void 

[58] 3GPP TS 33.221 "Generic Authentication Architecture (GAA); Support for Subscriber 

Certificates". 

[60] IEEE 1003.1-2004, Part 1: Base Definitions 

[61] 3GPP TS 43.318: "Generic Access to the A/Gb interface; Stage 2" 

[62] 3GPP TS 44.318: "Generic Access (GA) to the A/Gb interface; Mobile GA interface layer 3 

specification" 

[63] 3GPP TS 29. 163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and Circuit Switched (CS) networks" 

[64] IETF RFC 2606: "Reserved Top Level DNS Names" 

[65] Void 

[66] 3GPP TS 5 1 .01 1 Release 4: "Specification of the Subscriber Identity Module - Mobile Equipment 

(SIM - ME) interface" 

[67] 3GPP2 X.S0013-004: "IP Multimedia Call Control Protocol based on SIP and SDP; Stage 3" 

[68] 3GPP TS 23.402: "Architecture Enhancements for non-3GPP accesses" 

[69] 3GPP TS 33.402: "3GPP System Architecture Evolution: Security Aspects of non-3GPP accesses" 

[70] 3GPP TS 23.292: "IP Multimedia Subsystem (IMS) Centralized Services; Stage 2" 
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[71] 3GPP TS 23.237: "IP Multimedia Subsystem (IMS) Service Continuity" 

[72] 3GPP TS 23.401 : "General Packet Radio Service (GPRS) enhancements for Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN) access" 

[73] 3GPP TS 29.303: "Domain Name System Procedures; Stage 3" 

[74] IETF RFC 3958: "Domain-Based Application Service Location Using SRV RRs and the Dynamic 

Delegation Discovery Service (DDDS)" 

[75] Void 

[76] 3GPP TS 23.237: "Mobility between 3GPP- Wireless Local Area Network (WLAN) interworking 

and 3GPP systems" 

[77] 3GPP TS 24.302: "Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access 

networks; Stage 3" 

[78] 3GPP TS 23.273: "Evolved Packet System; 3GPP EPS AAA Interfaces" 

[79] IETF Internet-Draft, draft-montemurro-gsma-imei-urn-11 (October 2012): "A Uniform Resource 

Name Namespace For The GSM Association (GSMA) and the International Mobile station 
Equipment Identity (IMEI)". 

[80] IETF RFC 4122: "A Universally Unique IDentifier (UUID) URN Namespace". 

[81] 3GPP TS 24.229: "IP multimedia call control protocol based on Session Initiation Protocol (SIP) 

and Session Description Protocol (SDP); Stage 3". 

[82] IETF RFC5448: "Improved Extensible Authentication Protocol Method for 3rd Generation 

Authentication and Key Agreement (EAP-AKA') " 

[83] 3GPP TS 22.01 1: "Service accessibility". 

[84] 3GPP TS 36.413: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN) ; SI 

Application Protocol (SlAP)". 

[85] Guidelines for use of a 48-bit Extended Unique Identifier (EUI-48'™), 

http://standards . ieee.org/regauth/oui/tutorials/EUI48 . html 

[86] GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY, 

http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 

[87] The Broadband Forum TR-069: "CPE WAN Management Protocol vl . 1 ", Issue 1 Amendment 2, 

December 2007 

[88] 3GPP TS 29.274: "Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control 

plane (GTPv2-C); Stage 3". 

[89] 3GPP TS 33.401: "3GPP System Architecture Evolution: Security Architecture". 

[90] 3GPP TS 24.301 : "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); 

Stage 3". 

[91] 3GPP TS 36.300: " Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2". 

[92] 3GPP TS 23.216: "Single Radio Voice Call Continuity (SRVCC)". 

[93] 3GPP TS 3 1 . 103: "IP Multimedia Services Identity Module (ISIM) application". 

[94] IETF RFC 4825: "The Extensible Markup Language (XML) Configuration Access Protocol 

(XCAP)". 

[95] 3GPP TS 29.229: " Cx and Dx interfaces based on the Diameter protocol; Protocol details". 

[96] 3GPP TS 29.329: " Sh Interface based on the Diameter protocol; Protocol details". 
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[97] 3GPP TS 29. 165: "Inter-IMS Network to Network Interface (NNI); Stage 3". 

1 .1 .2 Informative references 

[44] "COMPLEMENT TO ITU-T RECOMMENDATION E.212 (1 1/98)", Annex to ITU Operational 

Bulletin No. 741 - 1. VI. 200; This is published on the ITU-T website, whose home page is at 
http://www.itu.int/ITU-T/ 

[57] GSMA PRD IR.34 "Inter-PLMN Backbone Guidelines" 

[59] Void 

1 .2 Abbreviations 

For the purposes of the present document, the abbreviations defined in 3GPP TS 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
3GPPTR 21.905 [1]. 

EPS Evolved Packet System 

GUTI Globally Unique Temporary UE Identity 

ICS IMS CentraUzed Services 

UUID Universally Unique IDentifier 

1 .3 General comments to references 

The identification plan for mobile subscribers defined below is that defined in ITU-T Recommendation E.212. 

The ISDN numbering plan for MSs and the allocation of mobile station roaming numbers is that defined in ITU-T 
Recommendation E.213. Only one of the principles for allocating ISDN numbers is proposed for PLMNs. Only the 
method for allocating MS roaming numbers contained in the main text of ITU-T Recommendation E.213 is 
recommended for use in PLMNs. If there is any difference between the present document and the ITU-T 
Recommendations, the former shall prevail. 

For terminology, see also ITU-T Recommendations E.164 and X.121. 



1 .4 Conventions on bit ordering 



The following conventions hold for the coding of the different identities appearing in the present document and in other 
GSM Technical Specifications if not indicated otherwise: 

the different parts of an identity are shown in the figures in order of significance; 

the most significant part of an identity is on the left part of the figure and the least significant on the right. 

When an identity appears in other Technical Specifications, the following conventions hold if not indicated otherwise: 

digits are numbered by order of significance, with digit 1 being the most significant; 

bits are numbered by order of significance, with the lowest bit number corresponding to the least significant bit. 



2 Identification of mobile subscribers 

2.1 General 

A unique International Mobile Subscriber Identity (IMSI) shall be allocated to each mobile subscriber in the 
GSM/UMTS/EPS system. 

NOTE: This IMSI is the concept referred to by ITU-T as "International Mobile Station Identity". 
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In order to support the subscriber identity confidentiality service the VLRs, SGSNs and MME may allocate Temporary 
Mobile Subscriber Identities (TMSI) to visiting mobile subscribers. The VLR,SGSN and MME must be capable of 
correlating an allocated TMSI with the IMSI of the MS to which it is allocated. 

An MS may be allocated three TMSIs, one for services provided through the MSC, one for services provided through 
the SGSN (P-TMSI for short) and one for the services provided via the MME (M-TMSI part GUTI for short). 

For addressing on resources used for GPRS, a Temporary Logical Link Identity (TLLI) is used. The TLLI to use is built 
by the MS either on the basis of the P-TMSI (local or foreign TLLI), or directly (random TLLI). 

In order to speed up the search for subscriber data in the VLR a supplementary Local Mobile Station Identity (LMSI) is 
defined. 

The LMSI may be allocated by the VLR at location updating and is sent to the HLR together with the IMSI. The HLR 
makes no use of it but includes it together with the IMSI in all messages sent to the VLR concerning that MS. 

2.2 Composition of IIVISI 

IMSI is composed as shown in figure I . 

K 

^ 3 digits 

MCC 



Not more than 15 digits 


"-^ 


.^1 ,/'2or3\. 


MNC MSIN 


,/ NMSI 


IMSI 


,--1 



K , 

Figure 1 : Structure of IMSI 

IMSI is composed of three parts: 

1) Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of 
the mobile subscriber; 

2) Mobile Network Code (MNC) consisting of two or three digits for GSM/UMTS applications. The MNC 
identifies the home PLMN of the mobile subscriber. The length of the MNC (two or three digits) depends on the 
value of the MCC. A mixture of two and three digit MNC codes within a single MCC area is not recommended 
and is outside the scope of this specification. 

3) Mobile Subscriber Identification Number (MSIN) identifying the mobile subscriber within a PLMN. 

The National Mobile Subscriber Identity (NMSI) consists of the Mobile Network Code and the Mobile Subscriber 
Identification Number. 

2.3 Allocation principles 

IMSI shall consist of decimal digits (0 through 9) only. 

The number of digits in IMSI shall not exceed 15. 

The allocation of Mobile Country Codes (MCCs) is administered by the ITU-T. The current allocation is given in the 
COMPLEMENT TO ITU-T RECOMMENDATION E.212 [44]. 

The allocation of National Mobile Subscriber Identity (NMSI) is the responsibility of each administration. 

If more than one PLMN exists in a country, the same Mobile Network Code should not be assigned to more than one 
PLMN. 
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The allocation of IMSIs should be such that not more than the digits MCC + MNC of the IMSI have to be analysed in a 
foreign PLMN for information transfer. 

2.4 Structure of TMS I 

Since the TMSI has only local significance (i.e. within a VLR and the area controlled by a VLR, or within an SGSN and 
the area controlled by an SGSN, or within an MME and the area controlled by an MME), the structure and coding of it 
can be chosen by agreement between operator and manufacturer in order to meet local needs. 

The TMSI consists of 4 octets. It can be coded using a full hexadecimal representation. 

In order to avoid double allocation of TMSIs after a restart of an allocating node, some part of the TMSI may be related 
to the time when it was allocated or contain a bit field which is changed when the allocating node has recovered from 
the restart. 

In areas where both MSC-based services and SGSN-based services are provided, some discrimination is needed 
between the allocation of TMSIs for MSC-based services and the allocation of TMSIs for SGSN-based services. The 
discrimination shall be done on the 2 most significant bits, with values 00, 01, and 10 being used by the VLR, and 1 1 
being used by the SGSN. 

If intra domain connection of RAN nodes to multiple CN nodes as described in 3GPP TS 23.236 [23] is applied in the 
MSC/VLR or SGSN, then the NRI shall be part of the TMSI. The NRI has a configurable length of to 10 bits. A 
configurable length of bits indicates that the NRI is not used and this feature is not applied in the MSC/VLR or SGSN. 
The NRI shall be coded in bits 23 to 14. An NRI shorter than 10 bits shall be encoded with the most significant bit of 
the NRI field in bit 23. 

The TMSI shall be allocated only in ciphered form. See also 3GPP TS 43.020 [7] and 3GPP TS 33.102 [42]. 

The network shall not allocate a TMSI with all 32 bits equal to 1 (this is because the TMSI must be stored in the SIM, 
and the SIM uses 4 octets with all bits equal to I to indicate that no valid TMSI is available). 

To allow for eventual modifications of the management of the TMSI code space management, MSs shall not check if an 
allocated TMSI belongs to the range allocated to the allocating node. MSs shall use an allocated TMSI according to the 
specifications, whatever its value. 

2.5 Structure of LMSI 

The LMSI consists of 4 octets and may be allocated by the VLR. The VLR shall not allocate the value zero. The value 
zero is reserved to indicate that an LMSI parameter sent from the HLR to the VLR shall not be interpreted. 

2.6 Structure of TLLI 

A TLLI is built by the MS or by the SGSN either on the basis of the P-TMSI (local or foreign TLLI), or directly 
(random or auxiliary TLLI), according to the following rules. 

The TLLI consists of 32 bits, numbered from to 31 by order of significance, with bit being the LSB. 

A local TLLI is built by an MS which has a valid P-TMSI as follows: 

bits 31 down to 30 are set to 1; and 

bits 29 down to are set equal to bits 29 to of the P-TMSI. 
A foreign TLLI is built by an MS which has a valid P-TMSI as follows: 

bit 3 1 is set to 1 and bit 30 is set to 0; and 

bits 29 down to are set equal to bits 29 to of the P-TMSI. 
A random TLLI is built by an MS as follows: 

bit 3 1 is set to 0; 
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bits 30 down to 27 are set to 1; and 

bits to 26 are chosen randomly. 
An auxiliary TLLI is built by the SGSN as follows: 

bit 31 is set to 0; 

bits 30 down to 28 are set to 1; 

bit 27 is set to 0; and 

bits to 26 can be assigned independently. 

Other types of TLLI may be introduced in the future. 

Part of the TLLI codespace is re-used in GERAN to allow for the inclusion of the GERAN Radio Network Temporary 
Identifier in RLC/MAC messages. The G-RNTI is defined in 3GPP TS 44. 1 18 [29]. 

The structure of the TLLI is summarised in table 1 . 

Table 1 : TLLI structure 
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'T', 'R', 'A' and 'X' indicate bits which can take any value for the type of TLLI. More precisely, 'T' indicates bits derived 
from a P-TMSI, 'R' indicates bits chosen randomly, A' indicates bits chosen by the SGSN, 'G' indicates bits derived 
from the assigned G-RNTI and 'X' indicates bits in reserved ranges. 

2.7 Structure of P-TMSI Signature 

The P-TMSI Signature consists of 3 octets and may be allocated by the SGSN. 

The network shall not allocate a P-TMSI Signature with all 24 bits equal to 1 (this is because the P-TMSI Signature 
must be stored in the SIM, and the SIM uses 3 octets with all bits equal to 1 to indicate that no valid P-TMSI signature 
is available. 

2.8 Globally Unique Temporary UE Identity (GUTI) 



2.8.1 



Introduction 



The purpose of the GUTI is to provide an unambiguous identification of the UE that does not reveal the UE or the user's 
permanent identity in the Evolved Packet System (EPS). It also allows the identification of the MME and network. It 
can be used by the network and the UE to establish the UE's identity during signalling between them in the EPS. See 
3GPPTS 23.401 [72]. 

The GUTI has two main components: 

one that uniquely identifies the MME which allocated the GUTI; and 

one that uniquely identifies the UE within the MME that allocated the GUTI. 
Within the MME, the mobile shall be identified by the M-TMSI. 
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The Globally Unique MME Identifier (GUMMEI) shall be constructed from the MCC, MNC and MME Identifier 

(MMEI). 

The MMEI shall be constructed from an MME Group ID (MMEGI) and an MME Code (MMEC). 

The GUTI shall be constructed from the GUMMEI and the M-TMSI. 

For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from the MMEC and the 
M-TMSI. 

The operator shall need to ensure that the MMEC is unique within the MME pool area and, if overlapping pool areas 
are in use, unique within the area of overlapping MME pools. 

The GUTI shall be used to support subscriber identity confidentiality, and, in the shortened S-TMSI form, to enable 
more efficient radio signalling procedures (e.g. paging and Service Request). 

The format and size of the GUTI is therefore the following: 

<GUTI> = <GUMMEI><M-TMSI>, 

where <GUMMEI> = <MCC><MNC><MME Identifier> 

and <MME Identifier> = <MME Group IDxMME Code> 
MCC and MNC shall have the same field size as in earlier 3GPP systems. 
M-TMSI shall be of 32 bits length. 
MME Group ID shall be of 16 bits length. 
MME Code shall be of 8 bits length. 



2.8.2 Mapping between Temporary and Area Identities for tine EUTRAN 
and tine UTRAN/GERAN based systems 

2.8.2.0 Introduction 

This section provides information on the mapping of the temporary and location area identities, e.g. for the construction 
of the Routeing Area Update Request message in GERAN/UTRAN or Tracking Area Update Request message in 
E-UTRAN. 

In GERAN and UTRAN: 

<RAI> = <MCC><MNC><LAC><RAC> 

<P-TMSI/TLLI> includes the mapped NRI 

P-TMSI shall be of 32 bits length where the two topmost bits are reserved and always set to '11'. Hence, for a UE which 
may handover to GERAN/UTRAN (based on subscription and UE capabilities), the corresponding bits in the M-TMSI 

are set to '11' (see subclause 2.8.2.1.3). 

3GPP TS 23.236 [23] specifies that the NRI field is of variable length and shall be mapped into the P-TMSI starting at 
bit 23 and down to bit 14. The most significant bit of the NRI is located at bit 23 of the P-TMSI regardless of the 
configured length of the NRI. To support mobility between GERAN/UTRAN and E-UTRAN, the NRI length is limited 
to a maximum of 8 bits to be compatible for the mapping to MME Code within GUTI (see subclause 2.8.2.2). 

The P-TMSI and NRI are defined elsewhere in this specification. 

In the case of a combined MME-SGSN node, the NRI of the SGSN part and the MME code of the MME part, refer to 
the same combined node. RAN configuration allows NAS messages on GERAN/UTRAN and E-UTRAN to be routed 
to the same combined node. The same or different values of NRI and MME code may be used for a combined node. 
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2.8.2.1 Mapping from GUTI to RAI, P-TMSI and P-TMSI signature 

2.8.2.1.1 Introduction 

This subclause addresses the case when a UE moves from an MME to an SGSN. The SGSN may be either an S4 SGSN 
or a Gn/Gp SGSN. 

2.8.2.1.2 Mapping in the UE 

When a UE moves from an E-UTRAN to a GERAN/UTRAN, the UE needs to map the GUTI to an RAI, a P-TMSI and 
a P-TMSI Signature, for them to be sent to the SGSN. For GERAN, the TLLI is derived from the P-TMSI by the UE 
and is a foreign TLLI (see subclause 2.6). 

The mapping of the GUTI shall be done to the combination of RAI of GERAN / UTRAN and the P-TMSI: 

E-UTRAN <MCC> maps to GERAN/UTRAN <MCC> 

E-UTRAN <MNC> maps to GERAN/UTRAN <MNC> 

E-UTRAN <MME Group ID> maps to GERAN/UTRAN <LAC> 

E-UTRAN <MME Code> maps to GERAN/UTRAN <RAC> and is also copied into the 8 most significant bits of 
the NRI field within the P-TMSI; 

E-UTRAN <M-TMSI> maps as follows: 

- 6 bits of the E-UTRAN <M-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and down to 
bit 24 of the GERAN/UTRAN <P-TMSI>; 

- 16 bits of the E-UTRAN <M-TMSI> starting at bit 15 and down to bit are mapped into bit 15 and down to 
bit of the GERAN/UTRAN <P-TMSI>; 

- and the remaining 8 bits of the E-UTRAN <M-TMSI> are mapped into the 8 MBS bits of the <P-TMSI 
signature> field. 

The remaining 2 octets of the <P-TMSI signature> shall be filled according to subclause 9.1.1 in 3GPP 
TS.33.401 [89]. 

For UTRAN, the 10-bit long NRI bits are masked out from the P-TMSI and are also supplied by the UE to the RAN 
node as IDNNS (Intra Domain NAS Node Selector) (see 3GPP TS 23.236 [23]). However, the RAN configured NRI 
length should not exceed 8 bits. 

2.8.2.1.3 Mapping in the old MME 

A new SGSN attempts to retrieve information regarding the UE, e.g. the IMSI, from the old MME. In order to find the 
UE context, the MME needs to map the RAI, P-TMSI (or TLLI) and the P-TMSI Signature (sent by the SGSN) to 
create the GUTI. 

The MME shall perform a reverse mapping to the mapping procedure specified in subclause 2.8.2.1.2 "Mapping in the 
UE" (see 3GPP TS 29.060 [6] and 3GPP TS 29.274 [88] for specifics of the messaging). For the reverse mapping, the 
E-UTRAN <MME Code> within the GUTI shall be set either to bits 23 to 16 of the GERAN/UTRAN <P-TMSI> (i.e., 
the NRI field) or to the GERAN/UTRAN <RAC>. For GERAN TLLI, the old MME replaces the two topmost bits of 
TLLI, received from new SGSN via GTPvl, with '11' before mapping the TLLI to the GUTI used for looking up the 
"UE Context". 

2.8.2.2 Mapping from RAI and P-TMSI to GUTI 



2.8.2.2.1 Introduction 

This subclause addresses the case when a UE moves from an SGSN to an MME. The SGSN may be either an S4 SGSN 
or a Gn/Gp SGSN. 



£75/ 



3GPP TS 23.003 version 1 0.6.0 Release 10 19 ETSI TS 1 23 003 VI 0.6.0 (201 3-01 ) 

2.8.2.2.2 Mapping in the UE 

When the UE moves from the GERAN/UTRAN to the E-UTRAN, the UE needs to map the RAI and P-TMSI to a 
GUTI to be sent to the MME. The P-TMSI signature is sent intact to the MME. 

The mapping of P-TMSI (TLLI) and RAI in GERAN/UTRAN to GUTI in E-UTRAN shall be performed as follows: 

GERAN/UTRAN <MCC> maps to E-UTRAN <MCC> 

GERAN/UTRAN <MNC> maps to E-UTRAN <MNC> 

GERAN/UTRAN <LAC> maps to E-UTRAN <MME Group ID> 

GERAN/UTRAN <RAC> maps into bit 23 and down to bit 16 of the M-TMSI 
The 8 most significant bits of GERAN/UTRAN <NRI> map to the MME code. 

GERAN/UTRAN <P-TMSI> maps as follows: 

- 6 bits of the GERAN/UTRAN <P-TMSI> starting at bit 29 and down to bit 24 are mapped into bit 29 and 
down to bit 24 of the E-UTRAN <M-TMSI>; 

- 16 bits of the GERAN/UTRAN <P-TMSI> starting at bit 15 and down to bit are mapped into bit 15 and 
down to bit of the E-UTRAN <M-TMSI>. 

The values of <LAC> and <MME group id> shall be disjoint, so that they can be differentiated. 

The most significant bit of the <LAC> shall be set to zero; and the most significant bit of <MME group id> shall be set 
to one. Based on this definition, the most significant bit of the <MME group id> can be used to distinguish the node 
type, i.e. whether it is an MME or SGSN. The UE copies the received old SGSN"s <LAC> into the <MME Group ID> 
when sending a message to an MME, regardless of the value of the most significant bit of the <LAC>. 
In networks where this definition is not applied (e.g. in networks already configured with LAC with the most significant 
bit set to 1 before LTE deployment), the information in the TAU/RAU request indicating whether the provided 
GUTI/P-TMSI is "native" (i.e. no system change) or "mapped" (i.e. system change) can be used to distinguish the node 
type for UEs implemented according to this release of the specification (see 3GPP TS 24.301 [90] and 3GPP TS 24.008 
[5]). Specific network implementations still satisfying 3GPP standard interfaces can be used for pre-Rel-10 UEs to 
distinguish the node type. 

NOTE 1: As an example, at NAS level, the MME/SGSN can retrieve the old SGSN/MME by using additional 

GUTI/additional RAI/P-TMSI with double DNS query to solve the first time the UE moves between E- 
UTRAN and GERAN/UTRAN. As another example, the MME/SGSN can retrieve the old SGSN/MME 
by using double DNS query. 

2.8.2.2.3 Mapping in the new MME 

In order to retrieve the UE's information, e.g. the IMSI, from the old SGSN, the new MME extracts the RAI and P- 
TMSI from the GUTI via the reverse mapping procedure to that specified in subclause 2.8.2.2.2. This is done in order to 
be able to include the RAI and P-TMSI, along with the P-TMSI Signature, in the corresponding message sent to the old 
SGSN (see 3GPP TS 29.060 [6] and 3GPP TS 29.274 [88] for specifics of the messaging). 

2.9 Structure of the S-Temporary Mobile Subscriber Identity (S- 
TMSI) 

The S-TMSI is the shortened form of the GUTI to enable more efficient radio signalling procedures (e.g. paging and 
Service Request). For paging purposes, the mobile is paged with the S-TMSI. The S-TMSI shall be constructed from 
the MMEC and the M-TMSI: 

<S-TMSI> = <MMEC><M-TMSI> 

See subclause 2.8 for these definitions and the mapping. 
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Numbering plan for mobile stations 



3.1 General 

The structure of the following numbers is defined below: 

the number used by a subscriber of a fixed (or mobile) network to call a mobile station of a PLMN; 

the network addresses used for packet data communication between a mobile station and a fixed (or mobile) 
station; 

mobile station roaming numbers. 

One or more numbers of the ISDN numbering plan shall be assigned to a mobile station to be used for all calls to that 
station, i.e. the assignment of at least one MSISDN to a mobile station is mandatory. 

NOTE: For card operated stations the ISDN number should be assigned to the holder of the card (personal 
number). 



3.2 Numbering plan requirements 



In principle, it should be possible for any subscriber of the ISDN or PSTN to call any MS in a PLMN. This implies that 
ISDN numbers for MSs should comply with the ISDN numbering plan in the home country of the MS. 

The ISDN numbers of MSs should be composed in such a way that standard ISDN/PSTN charging can be used for calls 
to MSs. 

It should be possible for each administration to develop its own independent numbering/addressing plan for MSs. 

The numbering/addressing plan should not limit the possibility for MSs to roam among PLMNs. 

It should be possible to change the IMSI without changing the ISDN number allocated to an MS and vice versa. 

In principle, it should be possible for any subscriber of the CSPDN/PSPDN to call any MS in a PLMN. This implies 
that it may be necessary for an MS to have a X.121 number. 

In principle, it should be possible for any fixed or mobile terminal to communicate with a mobile terminal using an IP 
v4 address or IP v6 address. 

3.3 Structure of MS international PSTN/ISDN number 
(MSISDN) 

MS international ISDN numbers are allocated from the ITU-T Recommendation E.164 numbering plan; see also ITU-T 
Recommendation E.213. The structure of the MS international ISDN number will then be as shown in figure 2. 



cc 



NDC SN 



National (significant) 
mobile number 
Mobile station international 
ISDN number 



Figure 2: Number Structure of MSISDN 
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The number consists of: 

Country Code (CC) of the country in which the MS is registered, followed by: 
National (significant) mobile number, which consists of: 
- National Destination Code (NDC) and 

Subscriber Number (SN). 

For GSM/UMTS applications, a National Destination Code is allocated to each PLMN. In some countries more than 
one NDC may be required for each PLMN. 

The composition of the MS international ISDN number should be such that it can be used as a global title address in the 
Signalling Connection Control Part (SCCP) for routeing messages to the home location register of the MS. The country 
code (CC) and the national destination code (NDC) will provide such routeing information. If further routeing 
information is required, it should be contained in the first few digits of the subscriber number (SN). 

A sub-address may be appended to an ISDN number for use in call setup and in supplementary service operations where 
an ISDN number is required (see ITU-T Recommendations E.164, clause 1 1.2 and X.213 annex A). The sub-address is 
transferred to the terminal equipment denoted by the ISDN number. 

The maximum length of a sub-address is 20 octets, including one octet to identify the coding scheme for the 
sub-address (see ITU-T Recommendation X.213, annex A). All coding schemes described in ITU-T Recommendation 
X.213, annex A are supported in GSM and UMTS. 

3.4 Mobile Station Roaming Number (IVISRN) for PSTN/ISDN 
routeing 

The Mobile Station Roaming Number (MSRN) is used to route calls directed to an MS. On request from the Gateway 
MSC via the HLR it is temporarily allocated to an MS by the VLR with which the MS is registered; it addresses the 
Visited MSC collocated with the assigning VLR. More than one MSRN may be assigned simultaneously to an MS. 

The MSRN is passed by the HLR to the Gateway MSC to route calls to the MS. 

The Mobile Station Roaming Number for PSTN/ISDN routing shall have the same structure as international ISDN 
numbers in the area in which the roaming number is allocated, i.e.: 

the country code of the country in which the visitor location register is located; 

the national destination code of the visited PLMN or numbering area; 

a subscriber number with the appropriate structure for that numbering area. 

The MSRN shall not be used for subscriber dialling. It should be noted that the MSRN can be identical to the MSISDN 
(clause 3.3) in certain circumstances. In order to discriminate between subscriber generated access to these numbers and 
re-routeing performed by the network, re-routeing or redirection indicators or other signalling means should be used, if 
available. 

3.5 Structure of IVIobile Station International Data Number 

The structure of MS international data numbers should comply with the data numbering plan of ITU-T 
Recommendation X.121 as applied in the home country of the mobile subscriber. Implications for numbering 
interworking functions which may need to be provided by the PLMN (if the use of X.121 numbers is required) are 
indicated in 3GPP TS 23.070 [4]. 

3.6 Handover Number 

The handover number is used for establishment of a circuit between MSCs to be used for a call being handed over. The 
structure of the handover number is the same as the structure of the MSRN. The handover number may be reused in the 
same way as the MSRN. 
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3.7 Structure of an IP v4 address 

One or more IP address domains may be allocated to each PLMN. The IP v4 address structure is defined in 
RFC 791 [14]. 

An IP v4 address may be allocated to an MS either permanently or temporarily during a connection with the network. 

3.8 Structure of an IP v6 address 

One or more IP address domains could be allocated to each PLMN. The IP v6 address structure is defined in 
RFC 2373 [15]. 

An IP v6 address may be allocated to an MS either permanently or temporarily during a connection with the network 

If the dynamic IPv6 stateless address autoconfiguration procedure is used, then each PDP context, or group of PDP 
contexts sharing the same IP address, is assigned a unique prefix as defined in 3GPP TS 23.060 [3]. 

As described in RFC 2462 [21] and RFC 3041 [22], the MS can change its interface identifier without the GPRS 
network being aware of the change. 



4 Identification of location areas and base stations 

4.1 Composition of the Location Area Identification (LAI) 

The Location Area Identification shall be composed as shown in figure 3: 



MCC 



MNC LAC 



^ — Location Area Identification — ^ 

Figure 3: Structure of Location Area Identification 

The LAI is composed of the following elements: 

- Mobile Country Code (MCC) identifies the country in which the GSM PLMN is located. The value of the MCC 
is the same as the three digit MCC contained in international mobile subscriber identity (IMSI); 

- Mobile Network Code (MNC) is a code identifying the GSM PLMN in that country. The MNC takes the same 
value as the two or three digit MNC contained in IMSI; 

Location Area Code (LAC) is a fixed length code (of 2 octets) identifying a location area within a PLMN. This 
part of the location area identification can be coded using a full hexadecimal representation except for the 
following reserved hexadecimal values: 

0000, and 

FFFE. 

These reserved values are used in some special cases when no valid LAI exists in the MS (see 3GPP TS 24.008 
[5], 3GPP TS 31.102 [27] and 3GPP TS 51.011 [9]). 

A specific GSM PLMN code (MCC + MNC) may be broadcast for mobile stations which are not compatible with 
SoLSA and which do not understand the exclusive access indicator (see 3GPP TS 23.073 [30]). The reserved value of 
the escape PLMN code is MCC = 901 and MNC = 08. 

4.2 Composition of the Routing Area Identification (RAI) 

The Routing Area Identification shall be composed as shown in figure 4: 
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Figure 4: Structure of Routing Area Identification 

The RAI is composed of the following elements: 

A valid Location Area Identity (LAI) as defined in clause 4.1. Invalid LAI values are used in some special cases 
when no valid RAI exists in the mobile station (see 3GPP TS 24.008 [5], 3GPP TS 31.102 [27] and 
3GPPTS 51.011 [9]). 

Routeing Area Code (RAC) which is a fixed length code (of 1 octet) identifying a routeing area within a location 
area. 



4.3 



Base station identification 



4.3.1 Cell Identity (CI) and Cell Global Identification (CGI) 

The BSS and cell within the BSS are identified within a location area or routeing area by adding a Cell Identity (CI) to 
the location area or routeing area identification, as shown in figure 5. The CI is of fixed length with 2 octets and it can 
be coded using a full hexadecimal representation. 

The Cell Global Identification is the concatenation of the Location Area Identification and the Cell Identity. Cell 
Identity shall be unique within a location area. 



MCC 



MNC 



LAC 



CI 



Location Area Identification 



K ^ 

Cell Global Identification (CGI) 

K -. 

Figure 5: Structure of Cell Global Identification 



4.3.2 Base Station Identify Code (BSIC) 



The base station identity code is a local colour code that allows an MS to distinguish between different neighbouring 
base stations. BSIC is a 6 bit code which is structured as shown in Figure 6. 
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Figure 6: Structure of BSIC 

In the definition of the NCC, care should be taken to ensure that the same NCC is not used in adjacent PLMNs which 
may use the same BCCH carrier frequencies in neighbouring areas. Therefore, to prevent potential deadlocks, a 
definition of the NCC appears in annex A. This annex will be reviewed in a co-ordinated manner when a PLMN is 
created. 
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4.4 Regional Subscription Zone Identity (RSZI) 

A PLMN-specific regional subscription defines unambiguously for the entire PLMN the regions in which roaming is 
allowed. It consists of one or more regional subscription zones. The regional subscription zone is identified by a 
Regional Subscription Zone Identity (RSZI). A regional subscription zone identity is composed as shown in figure 7. 

RSZI 



CC NDC 



ZC 



Zone Code, Two octets 



Figure 7: Structure of Regional Subscription Zone Identity (RSZI) 

The elements of the regional subscription zone identity are: 

1) the Country Code (CC) which identifies the country in which the PLMN is located; 

2) the National Destination Code (NDC) which identifies the PLMN in that country; 

3) the Zone Code (ZC) which identifies a regional subscription zone as a pattern of allowed and not allowed 
location areas uniquely within that PLMN. 

CC and NDC are those of an ITU-T E.164 VLR or SGSN number (see clause 5.1) of the PLMN; they are coded with a 
trailing filler, if required. ZC has fixed length of two octets and is coded in full hexadecimal representation. 

RSZIs, including the zone codes, are assigned by the VPLMN operator. The zone code is evaluated in the VLR or 
SGSN by information stored in the VLR or SGSN as a result of administrative action. If a zone code is received by a 
VLR or SGSN during updating by the HLR and this zone code is related to that VLR or SGSN, the VLR or SGSN shall 
be able to decide for all its MSC or SGSN areas and all its location areas whether they are allowed or not allowed. 

For details of assignment of RSZI and of ZC as subscriber data see 3GPP TS 23.008 [2]. 

For selection of RSZI at location updating by comparison with the leading digits of the VLR or SGSN number and for 
transfer of ZC from the HLR to VLR and SGSN see 3GPP TS 29.002 [31]. 

4.5 Location Number 

A location number is a number which defines a specific location within a PLMN. The location number is formatted 
according to ITU-T Recommendation E.164, as shown in figure 8. The Country Code (CC) and National Destination 
Code (NDC) fields of the location number are those which define the PLMN of which the location is part. 



CC 



NDC 



LSP 



Figure 8: Location Number Structure 

The structure of the locally significant part (LSP) of the location number is a matter for agreement between the PLMN 
operator and the national numbering authority in the PLMN's country. It is desirable that the location number can be 
interpreted without the need for detailed knowledge of the internal structure of the PLMN; the LSP should therefore 
include the national destination code in the national numbering plan for the fixed network which defines the geographic 
area in which the location lies. 

The set of location numbers for a PLMN shall be chosen so that a location number can be distinguished from the 
MSISDN of a subscriber of the PLMN. This will allow the PLMN to trap attempts by users to dial a location number. 
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4.6 Composition of the Service Area Identification (SAI) 

Void (see subclause 12.5). 

4.7 Closed Subscriber Group 

A Closed Subscriber Group consists of a single cell or a collection of cells within an E-UTRAN and UTRAN that are 
open to only a certain group of subscribers. 

Within a PLMN, a Closed Subscriber Group is identified by a Closed Subscriber Group Identity (CSG-ID). The 
CSG-ID shall be fix length 27 bit value. 

4.8 HNB Name 

HNB Name shall be a broadcast string in free text format that provides a human readable name for the Home NodeB or 
Home eNodeB CSG identity. 

HNB Name shall be coded in UTF-8 format with variable number of bytes per character. The maximum length of HNB 
Name shall be 48 bytes. 

See 3GPP TS 22.01 1 [83] for details. 



4.9 CSG Type 



CSG Type shall provide the type of a CSG identity in a human readable form. It shall reside in the UE only. See 3GPP 

TS 22.011 [83] for details. 

When the CSG Type has a text component, the CSG Type shall be coded in UTF-8 format with variable number of 
bytes per character . The maximum text length shall not exceed 12 characters in any language. 

4.10 HNB Unique Identity 

HNB Unique Identity uniquely identifies a Home NodeB or Home eNodeB. 

The HNB unique identity shall be defined as either a 48 -bit or 64-bit extended unique identifier (EUI-48 or EUI-64) as 
defined in [45] (EUI-48) and [46] (EUI-64). 

For use in HNB certificates, the HNB Unique Identity shall be transformed into a FQDN in the form: 

- <EUI-48/64>.<REALM> 

<EU148/64> is the first label which shall be the EUI-48 or EUI-64, represented as a string of 12 or 16 hexadecimal 
digits including any leading zeros. <REALM> denotes the realm which may consist of 3 labels , e.g. hnb. 
femtocellvendor. com. 



5 Identification of MSCs, GSNs and location registers 

5.1 Identification for routeing purposes 

MSCs, GSNs and location registers are identified by international PSTN/ISDN numbers and/or Signalling Point Codes 
("entity number", i.e., "HLR number", "VLR number", "MSC number", "SGSN number" and "GGSN number") in each 
PLMN. 

Additionally SGSNs and GGSNs are identified by GSN Addresses. These are the SGSN Address and the GGSN 
Address. 

A GSN Address shall be composed as shown in figure 9. 
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GSN Address 



-> 



Address Type 



Address Length 



Address 



<- 



2 bits 



> <- 



6 bits 



> ^ 



4 to 16 octets 



-> 



Figure 9: Structure of GSN Address 

The GSN Address is composed of the following elements: 

1) The Address Type, which is a fixed length code (of 2 bits) identifying the type of address that is used in the 
Address field. 

2) The Address Length, which is a fixed length code (of 6 bits) identifying the length of the Address field. 

3) The Address, which is a variable length field which contains either an IPv4 address or an IPv6 address. 
Address Type and Address Length 4 are used when Address is an IPv4 address. 

Address Type 1 and Address Length 16 are used when Address is an IPv6 address. 
The IP v4 address structure is defined in RFC 791 [14]. 
The IP v6 address structure is defined in RFC 2373 [15]. 

5.2 Identification of HLR for HLR restoration application 

HLR may also be identified by one or several "HLR id(s)", consisting of the leading digits of the IMSI (MCC + MNC + 
leading digits of MSIN). 

6 International Mobile Station Equipment Identity and 

Software Version Number 



6.1 



General 



The structure and allocation principles of the International Mobile station Equipment Identity and Software Version 
number (IMEISV) and the International Mobile station Equipment Identity (IMEI) are defined below. 

The Mobile Station Equipment is uniquely defined by the IMEI or the IMEISV. 

6.2 Composition of IMEI and IMEISV 
6.2.1 Composition of IMEI 

The International Mobile station Equipment Identity (IMEI) is composed as shown in figure 10. 
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8 digits 6 digits 1 digit 
< > < > < > 



^ 



TAG 



SNR 



IIVIEI 15 digits 



ccysD 



-> 



Figure 10: Structure of IMEI 

The IMEI is composed of the following elements (each element shall consist of decimal digits only): 

- Type Allocation Code (TAC). Its length is 8 digits; 

Serial Number (SNR) is an individual serial number uniquely identifying each equipment within the TAC. Its 
length is 6 digits; 

Check Digit (CD) / Spare Digit (SD): If this is the Check Digit see paragraph below; if this digit is Spare Digit it 
shall be set to zero, when transmitted by the MS. 

The IMEI (14 digits) is complemented by a Check Digit (CD). The Check Digit is not part of the digits transmitted 
when the IMEI is checked, as described below. The Check Digit is intended to avoid manual transmission errors, e.g. 
when customers register stolen MEs at the operator's customer care desk. The Check Digit is defined according to the 
Luhn formula, as defined in annex B. 

NOTE: The Check Digit is not applied to the Software Version Number. 

The security requirements of the IMEI are defined in 3GPP TS 22.016 [32]. 



6.2.2 Composition of IMEISV 



The International Mobile station Equipment Identity and Software Version Number (IMEISV) is composed as shown in 
figure 11. 



8 digits 6 digits 2 digits 
< > < > < > 



TAC 



SNR 



SVN 



<r 



IIVIEISV 16 digits 



-> 



Figure 1 1 : Structure of IIVIEISV 

The IMEISV is composed of the following elements (each element shall consist of decimal digits only): 

- Type Allocation Code (TAC). Its length is 8 digits; 

Serial Number (SNR) is an individual serial number uniquely identifying each equipment within each TAC. Its 
length is 6 digits; 

Software Version Number (SVN) identifies the software version number of the mobile equipment. Its length is 2 
digits. 

Regarding updates of the IMEISV: The security requirements of 3GPP TS 22.016 [32] apply only to the TAC and SNR, 
but not to the SVN part of the IMEISV. 
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6.3 Allocation principles 

The Type Allocation Code (TAC) is issued by a central body. 

Manufacturers shall allocate individual serial numbers (SNR) in a sequential order. 

For a given ME, the combination of TAC and SNR used in the IMEI shall duplicate the combination of TAC and SNR 
used in the IMEISV. 

The Software Version Number is allocated by the manufacturer. SVN value 99 is reserved for future use. 

7 Identification of Voice Group Call and Voice 

Broadcast Call Entities 

7.1 Group Identities 

Logical groups of subscribers to the Voice Group Call Service or to the Voice Broadcast Service are identified by a 
Group Identity (Group ID). Group IDs for VGCS are unique within a PLMN. Likewise, Group IDs for VBS are unique 
within a PLMN. However, no uniqueness is required between the sets of Group IDs. These sets may be intersecting or 
even identical, at the option of the network operator. 

The Group ID is a number with a maximum value depending on the composition of the voice group call reference or 
voice broadcast call reference defined in section 7.3. 

For definition of Group ID on the radio interface, A interface and Abis interface, see 3GPP TS 44.068 [46] and 3GPP 
TS 44.069 [47]. 

For definition of Group ID coding on MAP protocol interfaces, see 3GPP TS 29.002 [31]. 

VGCS or VBS shall also be provided for roaming. If this applies, certain Group IDs shall be defined as supra-PLMN 
Group IDs which have to be co-ordinated between the network operators and which shall be known in the networks and 
in the SIM. 

The format of the Group ID is identical for VBS and VGCS. 



7.2 Group Call Area Identification 



Grouping of cells into specific group call areas occurs in support of both the Voice Group Call Service and the Voice 
Broadcast Service. These service areas are known by a "Group Call Area Identity" (Group Call Area Id). No restrictions 
are placed on what cells may be grouped into a given group call area. 

The Group Call Area ID is a number uniquely assigned to a group call area in one network and with a maximum value 
depending on the composition of the voice group call reference or voice broadcast reference defined under 7.3. 

The formats of the Group Call Area ID for VGCS and the Group Call Area ID for VBS are identical. 

7.3 Voice Group Call and Voice Broadcast Call References 

Specific instances of voice group calls (VGCS) and voice broadcast calls (VBS) within a given group call area are 
known by a "Voice Group Call Reference" or by a "Voice Broadcast Call Reference" respectively. 

Each voice group call or voice broadcast call in one network is uniquely identified by its Voice Group Call Reference or 
Voice Broadcast Call Reference. The Voice Group Call Reference or Voice Broadcast Call Reference is composed of 
the Group ID and the Group Call Area ID. The composition of the group call area ID and the group ID can be specific 
for each network operator. 

For definition of Group Call Reference (with leading zeros inserted as necessary) on the radio interface, A interface and 
Abis interface, see 3GPP TS 24.008 [5], 3GPP TS 44.068 [46] and 3GPP TS 44.069 [47]. 
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For definition of Group Call Reference (also known as ASCI Call Reference, Voice Group Call Reference or Voice 
Broadcast Call Reference) coding on MAP protocol interfaces, see 3GPP TS 29.002 [31]. 

The format is given in figure 12. 



Group 
Call 
Area ID 



Group ID 



Voice Group Call Reference / 
Voice Broadcast Call Reference 

K ^ 



Figure 12: Voice Group Call Reference / Voice Broadcast Call Reference 



8 SCCP subsystem numbers 



Subsystem numbers are used to identify applications within network entities which use SCCP signalling. In GSM and 
UMTS, subsystem numbers may be used between PLMNs, in which case they are taken from the globally standardized 
range (1 - 31) or the part of the national network range (129 - 150) reserved for GSM/UMTS use between PLMNs. For 
use within a PLMN, they are taken from the part of the national network range (32 - 128 & 151 - 254) not reserved for 
GSM/UMTS use between PLMNs. 

8.1 Globally standardized subsystem numbers used for 
GSM/UMTS 

The following globally standardised subsystem numbers have been allocated for use by GSM/UMTS: 
OOOOOllOHLR(MAP); 
OOOOOlllVLR(MAP); 
0000 lOOOMSC (MAP); 
0000 lOOlEIR (MAP); 
0000 lOlOis allocated for evolution (possible Authentication Centre). 

8.2 National network subsystem numbers used for GSIVI/UIVITS 

The following national network subsystem numbers have been allocated for use within GSM/UMTS networks: 

nil lOOlPCAP; 

nil lOlOBSC (BSSAP-LE); 

nil lOllMSC (BSSAP-LE); 

11111 lOOSMLC (BSSAP-LE); 

11111 lOlBSS O&M (A interface); 

111111 lOBSSAP (A interface). 

The following national network subsystem numbers have been allocated for use within and between GSM/UMTS 
networks: 

1000 lllORANAP; 
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1000 11 URNS AP; 

1001 OOOIGMLC (MAP); 

1001 OOIOCAP; 

1001 OOllgsmSCF (MAP) or IM-SSF (MAP) or Presence Network Agent; 
1001 OlOOSIWF (MAP); 
1001 OIOISGSN (MAP); 
lOOlOllOGGSN(MAP). 



9 Definition of Access Point Name 

In the GPRS backbone, an Access Point Name (APN) is a reference to a GGSN. To support inter-PLMN roaming, the 
internal GPRS DNS functionality is used to translate the APN into the IP address of the GGSN. 

9.0 General 

Access Point Name as used in the Domain Name System (DNS) Procedures defined in 3GPP TS 29.303 [73] is 
specified in subclause 19.4.2.2. 

9.1 Structure of APN 

The APN is composed of two parts as follows: 

• The APN Network Identifier; this defines to which external network the GGSN/PGW is connected and 
optionally a requested service by the MS. This part of the APN is mandatory. 

• The APN Operator Identifier; this defines in which PLMN GPRS/EPS backbone the GGSN/PGW is located. 
This part of the APN is optional. 

The APN Operator Identifier is placed after the APN Network Identifier. An APN consisting of both the Network 
Identifier and Operator Identifier corresponds to a DNS name of a GGSN/PGW; the APN has, after encoding as defined 
in the paragraph below, a maximum length of 100 octets. 

The encoding of the APN shall follow the Name Syntax defined in RFC 2181 [18], RFC 1035 [19] and RFC 1123 [20]. 
The APN consists of one or more labels. Each label is coded as a one octet length field followed by that number of 
octets coded as 8 bit ASCII characters. Following RFC 1035 [19] the labels shall consist only of the alphabetic 
characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following RFC 1 123 [20], the label shall begin and end with 
either an alphabetic character or a digit. The case of alphabetic characters is not significant. The APN is not terminated 
by a length byte of zero. 

NOTE: A length byte of zero is added by the SGSN/MME at the end of the APN before interrogating a DNS 
server. 

For the purpose of presentation, an APN is usually displayed as a string in which the labels are separated by dots (e.g. 
"Labell.Label2.Label3"). 

9.1 .1 Format of APN Network Identifier 

The APN Network Identifier shall contain at least one label and shall have, after encoding as defined in subclause 9.1 
above, a maximum length of 63 octets. An APN Network Identifier shall not start with any of the strings "rac", "lac", 
"sgsn" or "rnc", and it shall not end in ".gprs", i.e. the last label of the APN Network Identifier shall not be "gprs". 
Further, it shall not take the value "*". 
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In order to guarantee uniqueness of APN Network Identifiers within or between GPRS/EPS PLMN, an APN Network 
Identifier containing more than one label shall correspond to an Internet domain name. This name should only be 
allocated by the PLMN if that PLMN belongs to an organisation which has officially reserved this name in the Internet 
domain. Other types of APN Network Identifiers are not guaranteed to be unique within or between GPRS/EPS 
PLMNs. 

An APN Network Identifier may be used to access a service associated with a GGSN/PGW. This may be achieved by 
defining: 

an APN which corresponds to a FQDN of a GGSN/PGW, and which is locally interpreted by the GGSN/PGW 
as a request for a specific service, or 

an APN Network Identifier consisting of 3 or more labels and starting with a Reserved Service Label, or an 
APN Network Identifier consisting of a Reserved Service Label alone, which indicates a GGSN/PGW by the 
nature of the requested service. Reserved Service Labels and the corresponding services they stand for shall be 
agreed between operators who have GPRS/EPS roaming agreements. 



9.1 .2 Format of APN Operator Identifier 



The APN Operator Identifier is composed of three labels. The last label (or domain) shall be "gprs". The first and 
second labels together shall uniquely identify the GPRS/EPS PLMN. 

For each operator, there is a default APN Operator Identifier (i.e. domain name). This default APN Operator Identifier 
is derived from the IMSI as follows: 

" mnc<MNC>. mcc<MCC> . gprs " 

where: 

"mnc" and "mcc" serve as invariable identifiers for the following digits. 

<MNC> and <MCC> are derived from the components of the IMSI defined in subclause 2.2. 

This default APN Operator Identifier is used in inter-PLMN roaming situations when attempting to translate an APN 
consisting only of a Network Identifier into the IP address of the GGSN/PGW in the HPLMN. The PLMN may provide 
DNS translations for other, more human-readable, APN Operator Identifiers in addition to the default Operator 
Identifier described above. 

In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the 
"mnc<MNC>.mcc<MCC>.gprs" format of the APN 01 shall be: 

• <MNC> = 3 digits 

• <MCC> = 3 digits 

• If there are only 2 significant digits in the MNC, one "0" digit is inserted at the left side to fill the 3 digits 
coding of MNC in the APN OI. 

As an example, the APN OI for MCC 345 and MNC 12 will be coded in the DNS as "mnc012.mcc345.gprs". 

The format of the domain name used in the APN-OI replacement field (as defined in 3GPP TS 23.060 [3] and 3GPP TS 
23.401 [72]) is the same as the default APN-OI as defined above except that it may be preceded by one or more labels 
each separated by a dot. 

EXAMPLE 1: provinceLmnc012.mcc345.gprs 

EXAMPLE 2: ggsn-cluster-A.provinceB.mnc012.mcc345.gprs 

The APN constructed using the APN-OI replacement field is only used for DNS translation. The APN when being sent 
to other network entities over GTP interfaces shall follow the rules as specified in 3GPP TS 23.060 [3] and 3GPP TS 
23.401 [72]. 
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9.2 Definition of the Wild Card APN 

The APN field in the HLR may contain a wild card APN if the HPLMN operator allows the subscriber to access any 
network of a given PDP Type. If an SGSN has received such a wild card APN, it may either choose the APN Network 
Identifier received from the Mobile Station or a default APN Network Identifier for addressing the GGSN when 
activating a PDP context. 

9.2.1 Coding of the Wild Card APN 

The wild card APN is coded as an APN with "*" as its single label, (i.e. a length octet with value one, followed by the 
ASCII code for the asterisk). 

9.3 Definition of Emergency APN 

The Emergency APN (Em- APN) is an APN used to derive a PDN GW selected for IMS Emergency call support. The 
exact encoding of the Em- APN is the responsibility of each PLMN operator as it is only valid within a given PLMN. 



1 Identification of the Cordless Telephony System 
entities 

10.1 General description of CTS-MS and CTS-FP Identities 

Every CTS-FP broadcasts a local identity - the Fixed Part Beacon Identity (FPBI) - which contains an Access Rights 
Identity. Every CTS-MS has both an Access Rights Key and a CTS Mobile Subscriber Identity (CTSMSI). These 
operate as a pair. A CTS-MS is allowed to access any CTS-FP which broadcasts an FPBI which can be identified by 
any of the CTS-MS Access Rights Keys of that CTS-MS. The CTS-MS Access Rights Key contains the FPBI and the 
FPBI Length Indicator (FLI) indicating the relevant part of the FPBI used to control access. 

1 0.2 CTS Mobile Subscriber Identities 
10.2.1 General 

Each CTS-MS has one or more temporary identities which are used for paging and to request access. The structure and 
allocation principles of the CTS Mobile Subscriber Identities (CTSMSI) are defined below. 



1 0.2.2 Composition of the CTSMSI 



bit No 22 1 

+ + 

Type I < Significant Part > | 

CTSMSI 22 bits 



Figure 13: Structure of CTSMSI 

The CTSMSI is composed of the following elements: 

- CTSMSI Type. Its length is 2 bits; 
Significant Part. Its length is 20 bits. 
The following CTSMSI Type values have been allocated for use by CTS: 

00 Default Individual CTSMSI; 
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01 Reserved; 

10 Assigned Individual CTSMSI; 

1 1 Assigned Connectionless Group CTSMSI. 

10.2.3 Allocation principles 

The default Individual CTSMSI contains the least significant portion of the IMSI. This is the default CTS-MS identity. 

Assigned CTSMSIs are allocated by the CTS-FP during enrolment, registration and other access procedures. Significant 
Part of the assigned CTSMSI shall be allocated in the range 00001-FFFFE. CTS-FP shall not allocate Significant Part 
equal to 00000 or to FFFFF and shall not allocate Assigned CTSMSI using Reserved Type value. Such assignments 
shall be ignored by the CTS-MS. 

Assigned CTSMSIs are allocated in ciphered mode. 

NOTE: The assigned individual CTSMSI should be updated whenever it is sent in clear text on the CTS radio 
interface during RR connection establishment. 

The value FFFFF from the set of Assigned Connectionless Group CTSMSI shall be considered in all CTS-MS as the 
value of the Connectionless Broadcast Identifier. 

10.2.4 CTSMSI hexadecimal representation 

The 22 bits of CTSMSI are padded with 2 leading zeroes to give a 6 digit hexadecimal value. 
EXAMPLE: binary CTSMSI value: 1 1 1001 0010 0000 101 1 1 100 
hexadecimal CTSMSI value: 39 20 BC. 

10.3 Fixed Part Beacon Identity 
10.3.1 General 

Each CTS-FP has one Fixed Part Beacon Identity known by the enrolled CTS-MSs. The FPBI is periodically broadcast 
on the BCH logical channel so that the CTS-MSs are able to recognise the identity of the CTS-FP. The FPBI contains 
an Access Rights Identity. 

Enrolled CTS-MSs shall store the FPBI to which their assigned CTSMSIs are related. 

Below the structure and allocation principles of the Fixed Part Beacon Identity (FPBI) are defined. 



1 0.3.2 Composition of the FPBI 
1 0.3.2.1 FPBI general structure 



bit No 19 1 

+ + 

|_±_1_±_±_±_±_±_±_±_±_±_±_±_±_±_±_±_±_| 
Type I Significant Part | 

FPBI 19 bits 
< > 

Figure 14: General structure of FPBI 

The FPBI is composed of the following elements: 
- FPBI Type. Its length is 2 bits; 
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- FPBI Significant Part. Its length is 17 bits. 

NOTE: The three LSBs bits of the FPBI form the 3-bit training sequence code (TSC). See 3GPP TS 45.056 [35]. 
The following FPBI Type values have been allocated for use by CTS: 

00 FPBI class A: residential and single-cell systems; 

01 FPBI class B: multi-cell PABXs. 

All other values are reserved and CTS-MSs shall treat these values as FPBI class A. 

10.3.2.2 FPBI class A 

This class is intended to be used for small residential and private (PBX) single cell CTS-FP. 

bit No 19 1 

|o"oj I 

Type I FPN I 

FPBI 19 bits 
< > 

Figure 15: Structure of FPBI class A 

The FPBI class A is composed of the following elements: 

FPBI Class A Type. Its length is 2 bits and its value is 00; 

Fixed Part Number (FPN). Its length is 17 bits. The FPN contains the least significant bits of the Serial Number 
partofthelFPEI. 

The FPBI Length Indicator shall be set to 19 for a class A FPBI. 

10.3.2.3 FPBI class B 

This class is reserved for more complex private installation such as multi-cell PABXs. 

bit No 19 1 

+ + 

Type I CNN + FPN + RPN j 

FPBI 19 bits 
< > 

Figure 16: Structure of FPBI class B 

The FPBI class B is composed of the following elements: 

FPBI Class B Type. Its length is 2 bits and its value is 01; 

CTS Network Number (CNN). Its length is defined by the manufacturer or the system installer; 

Fixed Part Number (FPN). Its length is defined by the manufacturer or the system installer; 

Radio Part Number (RPN) assigned by the CTS manufacturer or system installer. Its length is defined by the 
manufacturer or the system installer. 

NOTE: RPN is used to separate a maximum of 2'*'"'^ '''"'^* different cells from each other. This defines a cluster of 
cells supporting intercell handover. RPN length is submitted to a CTS-MS as a result of a successful 
attachment. 

The FPBI Length Indicator shall be set to (2 + CNN Length) for a class B FPBI. 
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10.3.3 Allocation principles 

The FPBI shall be allocated during the CTS-FP initialisation procedure. Any change to the value of the FPBI of a given 
CTS-FP shall be considered as a CTS-FP re-initialisation; i.e. each enrolled CTS-MS needs to be enrolled again. 

FPBI are not required to be unique (i.e. several CTS-FP can have the same FPBI in different areas). Care should be 
taken to limit CTS-MS registration attempts to a fixed part with the same FPBI as another fixed part. 

10.4 International Fixed Part Equipment Identity 
10.4.1 General 

The structure and allocation principles of the International Fixed Part Equipment Identity (IFPEI) are defined below. 



1 0.4.2 Composition of the IFPEI 



6 digits 2d 6 digits 2d 
< >< >< >< > 

+ + + + + + + + 

TAC FAC SNR SVN 

IFPEI 16 digits 
< > 

Figure 17: Structure of IFPEI 

The IFPEI is composed of the following elements (each element shall consist of decimal digits only): 

Type Approval Code (TAC). Its length is 6 decimal digits; 

Final Assembly Code (FAC). Its length is 2 decimal digits; 

Serial NumbeR (SNR). Its length is 6 decimal digits; 

Software Version Number (SVN) identifies the software version number of the fixed part equipment. Its length 
is 2 digits. 

Regarding updates of the IFPEI: the TAC, FAC and SNR shall be physically protected against unauthorised change (see 
3GPP TS 42.009 [36]); i.e. only the SVN part of the IFPEI can be modified. 

10.4.3 Allocation principles 

The Type Approval Code (TAC) is issued by a central body. 

The place of final assembly (FAC) is encoded by the manufacturer. 

Manufacturers shall allocate unique serial numbers (SNR) in a sequential order. 

The Software Version Number (SVN) is allocated by the manufacturer after authorisation by the type approval 
authority. SVN value 99 is reserved for future use. 

10.5 International Fixed Part Subscription Identity 
10.5.1 General 

The structure and allocation principles of the International Fixed Part Subscription Identity (IFPSI) are defined below. 
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1 0.5.2 Composition of tine IFPSI 

No more than 15 digits 
< > 

3d 3d 

< X X // > 

+ + + + + // + 

[.±.±.[[.±.±.[[.±.±.±//±.±.±.±.[ 

MCC CON FPIN 

NFPSI 



IFPSI 



Figure 18: Structure of IFPSI 

The IFPSI is composed of the following elements (each element shall consist of decimal digits only): 

- Mobile Country Code (MCC) consisting of three digits. The MCC identifies the country of the CTS-FP 
subscriber (e.g. 208 for France); 

- CTS Operator Number (CON). Its length is three digits; 

Fixed Part Identification Number (FPIN) identifying the CTS-FP subscriber. 

The National Fixed Part Subscriber Identity (NFPSI) consists of the CTS Operator Number and the Fixed Part 
Identification Number. 

10.5.3 Allocation principles 

IFPSI shall consist of decimal characters (0 to 9) only. 

The allocation of Mobile Country Codes (MCCs) is administered by the ITU-T. 

The allocation of CTS Operator Number (CON) and the structure of National Fixed Part Subscriber Identity (NFPSI) 
are the responsibility of each National Regulation Authority. 

CTS Operators shall allocate unique Fixed Part Identification Numbers. 

1 1 Identification of Localised Service Area 

Cells may be grouped into specific localised service areas. Each localised service area is identified by a localised 
service area identity (LSA ID). No restrictions are placed on what cells may be grouped into a given localised service 
area. 

The LSA ID can either be a PLMN significant number or a universal identity. This shall be known both in the networks 
and in the SIM. 

The LSA ID consists of 24 bits, numbered from to 23, with bit being the LSB. Bit indicates whether the LSA is a 
PLMN significant number or a universal LSA. If the bit is set to the LSA is a PLMN significant number; if it is set to 
1 it is a universal LSA. 

The LSA ID shall be composed as shown in figure 19: 
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Figure 19: Structure of LSA ID 



12 Identification of PLIVIN, RNC, Service Area, CN 
domain and Shared Network Area 

The following clauses describe identifiers which are used by both the CN and the UTRAN across the lu interface. For 
identifiers which are solely used within the UTRAN, see 3GPP TS 25.401 [16]. 

NOTE: in the following subclauses, the double vertical bar notation II indicates the concatenation operator. 

12.1 PLMN Identifier 

A Public Land Mobile Network is uniquely identified by its PLMN identifier. PLMN -Id consists of Mobile Country 
Code (MCC) and Mobile Network Code (MNC). 

- PLMN-Id = MCC II MNC 

The MCC and MNC are predefined within a UTRAN, and set in the RNC via O&M. 

12.2 CN Domain Identifier 

A CN Domain Edge Node is identified within the UTRAN by its CN Domain Identifier. The CN Domain identifier is 
used over UTRAN interfaces to identify a particular CN Domain Edge Node for relocation purposes. The CN Domain 
identifier for Circuit Switching (CS) consists of the PLMN-Id and the LAC, whereas for Packet Switching (PS) it 
consists of the PLMN-Id, the LAC, and the RAC of the first accessed cell in the target RNS. 

The two following CN Domain Identifiers are defined: 

- CN CS Domain-Id = PLMN-Id II LAC 

- CN PS Domain-Id = PLMN-Id II LAC II RAC 

The LAC and RAC are defined by the operator, and set in the RNC via O&M. 

For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. 

12.3 CN Identifier 

A CN node is uniquely identified within a PLMN by its CN Identifier (CN-Id). The CN-Id together with the PLMN 
identifier globally identifies the CN node. The CN-Id together with the PLMN-Id is used as the CN node identifier in 
RANAP signalling over the lu interface. 

Global CN-Id = PLMN-Id II CN-Id 

The CN-Id is defined by the operator, and set in the nodes via O&M. 

For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. 
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12.4 RNC Identifier 

An RNC node is uniquely identified by its RNC Identifier (RNC-Id). The RNC-Id of an RNC is used in the UTRAN, in 
a GERAN which is operating in GERAN lu mode and between them. A BSC which is part of a GERAN operating in lu 
mode is uniquely identified by its RNC Identifier (RNC-Id). The RNC-Id of a BSC is used in a GERAN which is 
operating in GERAN lu mode, in the UTRAN and between them. RNC-Id together with the PLMN identifier globally 
identifies the RNC. The RNC-Id on its own or the RNC-Id together with the PLMN-Id is used as the RNC identifier in 
the UTRAN lub, lur and lu interfaces. The SRNC-Id is the RNC-Id of the SRNC. The C-RNC-Id is the RNC-Id of the 
controlling RNC. The D-RNC-Id is the RNC Id of the drift RNC. 

- Global RNC-Id = PLMN-Id II RNC-Id 

The RNC-Id is defined by the operator, and set in the RNC via O&M 

For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. 

For the usage of this identifier on lur-g, see 3GPP TS 43.130 [43]. 

12.5 Service Area Identifier 

The Service Area Identifier (SAI) is used to identify an area consisting of one or more cells belonging to the same 
Location Area. Such an area is called a Service Area and can be used for indicating the location of a UE to the CN. 

The Service Area Code (SAC) together with the PLMN-Id and the LAC constitute the Service Area Identifier. 

- SAI = PLMN-Id 1 1 LAC 1 1 SAC 

The SAC is defined by the operator, and set in the RNC via O&M. 

For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. 

3GPP TS 25.423 [37] and 3GPP TS 25.419 [38] define the use of this identifier in RNSAP and SABP signalling. 

A cell may belong to one or two Service Areas. If it belongs to two Service Areas, one is applicable in the Broadcast 
(BC) domain and the other is applicable in both the CS and PS domains. 

The Broadcast (BC) domain requires that its Service Areas each consist of only one cell. This does not limit the use of 
Service Areas for other domains. Refer to 3GPP TS 25.410 [39] for a definition of the BC domain. 

12.6 Shared Network Area Identifier 

The Shared Network Area Identifier (SNA-Id) is used to identify an area consisting of one or more Location Areas. 
Such an area is called a Shared Network Area and can be used to grant access rights to parts of a Shared Network to a 
UE in connected mode (see 3GPP TS 25.401 [39]). 

The Shared Network Area Identifier consists of the PLMN-Id followed by the Shared Network Area Code (SNAC). 

- SNA-Id = PLMN-Id II SNAC 
The SNAC is defined by the operator. 

For the syntax description and the use of this identifier in RANAP signalling, see 3GPP TS 25.413 [17]. 

13 Numbering, addressing and identification within the 
IP multimedia core network subsystem 

13.1 Introduction 

This clause describes the format of the parameters needed to access the IP multimedia core network subsystem. For 
further information on the use of the parameters see 3GPP TS 23.228 [24] and 3GPP TS 29.163 [63]. For more 
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information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document. For 
more information on the ".invalid" top level domain see IETF RFC 2606 [64]. 

13.2 Home network domain name 

The home network domain name shall be in the form of an Internet domain name, e.g. operator.com, as specified in 
IETF RFC 1035 [19]. 

For 3GPP systems, if there is no ISIM application, the UE shall derive the home network domain name from the IMSI 
as described in the following steps: 

1. Take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27]) and 
separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning. 

2. Use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>. 3gppnetwork.org" domain 
name. 

3. Add the label "ims." to the beginning of the domain. 
An example of a home network domain name is: 

IMSI in use: 234150999999999; 
where: 

- MCC = 234; 

- MNC = 15; and 

- MSIN = 0999999999, 

which gives the home network domain name: ims.mnc015.mcc234.3gppnetwork.org. 

For 3GPP2 systems, if there is no IMC present, the UE shall derive the home network domain name as described in 
Annex C of 3GPP2 X.S0013-004 [67]. 



13.3 Private User Identity 



The private user identity shall take the form of an NAI, and shall have the form usemame ©realm as specified in clause 
2.1 of IETF RFC 4282 [53]. 

NOTE: It is possible for a representation of the IMSI to be contained within the NAI for the private identity. 

For 3GPP systems, if there is no ISIM application, the private user identity is not known. If the private user identity is 
not known, the private user identity shall be derived from the IMSI. 

The following steps show how to build the private user identity out of the IMSI: 

1 . Use the whole string of digits as the username part of the private user identity; and 

2. convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in subclause 13.2. 

The result will be a private user identity of the form "<IMSI>@ims.mnc<MNC>.mcc<MCC>. 3gppnetwork.org". For 
example: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the private user identity then takes the form 
"234150999999999@ims.mnc015.mcc234.3gppnetwork.org". 

For 3GPP2 systems, if there is no IMC present, the UE shall derive the private user identity as described in Annex C of 
3GPP2X.S0013-004[67]. 



13.4 Public User Identity 



A Public User Identity is any identity used by a user within the IMS subsystem for requesting communication to another 
user. 
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The Public User Identity shall take the form of either a SIP URI (see IETF RFC 3261 [26]) or a Tel URI (see IETF RFC 
3966 [45]). 

The 3GPP specifications describing the interfaces over which Public User Identities are transferred specify the allowed 
Public User Identity formats, in particular 3GPP TS 24.229 [81] for SIP signalling interfaces, 3GPP TS 29.229 [95] for 
Cx and Dx interfaces, 3GPP TS 29.329 [96] for Sh interface, 3GPP TS 29.165 [97] for II-NNI interface. 

In the case the user identity is a telephone number, it shall be represented either by a Tel URI or by a SIP URI that 
includes a 'user=phone' URI parameter and a "userinfo" part that shall follow the same format as the Tel URI. 

According to 3GPP TS 24.229 [81], the UE can use either: 

- a global number as defined in IETF RFC 3966 [45] and following E.164 format, as defined by ITU-T 

Recommendation E.164 [10] or 

- a local number, that shall include a 'phone-context' parameter that identifies the scope of its validity, as per IETF 

RFC 3966 [45]. 

According to 3GPP TS 29.165 [97] a global number as defined in IETF RFC 3966 [45] shall be used in a tel-URI or in 
the user portion of a SIP URI with the user=phone parameter when conveyed via a non-roaming II-NNI except when 
agreement exists between the operators to also allow other kinds of numbers. 

According to 3GPP TS 29.229 [95] and 3GPP TS 29.329 [96] the canonical forms of SIP URI and Tel URI shall be 
used over the corresponding Diameter interfaces. 

The canonical form of a SIP URI for a Public User Identity shall take the form "sip:username@domain" as specified in 
IETF RFC 3261 [26], section 10.3. SIP URI comparisons shall be performed as defined in IETF RFC 3261 [26], section 
19.1.4. 

The canonical form of a Tel URI for a Public User Identity shall take the form 'tel:H-<CC><NDC><SN>' (max number 
of digits is 15), that represents an E.164 number and shall contain a global number without parameters and visual 
separators (see IETF RFC 3966[45], section 3). Tel URI comparisons shall be performed as defined in IETF RFC 

3966[45], section 4. 

Public User Identities are stored in the HSS either as a distinct Public User Identity or as a Wildcarded Public User 
Identity. A distinct Public User Identity contains the Public User Identity that is used in routing and it is explicitly 
provisioned in the HSS. 



13.4A Wildcarded Public User Identity 



Public User Identities may be stored in the HSS as Wildcarded Public User Identities. A Wildcarded Public User 
Identity represents a collection of Public User Identities that share the same service profile and are included in the same 
implicit registration set. Wildcarded Public User Identities enable optimisation of the operation and maintenance of the 
nodes for the case in which a large amount of users are registered together and handled in the same way by the network. 
The format of a Wildcarded Public User Identity is the same as for the Wildcarded PSI described in subclause 13.5. 



13.4B Temporary Public User Identity 



For 3GPP systems, if there is no ISIM application to host the Public User Identity, a Temporary Public User Identity 
shall be derived, based on the IMSI. The Temporary Public User Identity shall be of the form as described in sub-clause 
13.4 and shall consist of the string "sip:" appended with a username and domain portion equal to the IMSI derived 
Private User Identity, as described in sub-clause 13.2. An example using the same example IMSI from sub-clause 13.2 
can be found below: 

EXAMPLE: "sip:234150999999999@ims.mnc015.mcc234.3gppnetwork.org". 

For 3GPP2 systems, if there is no IMC present, the UE shall derive the public user identity as described in Annex C of 
3GPP2X.S0013-004[67]. 
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1 3.5 Public Service Identity (PSI) 



The public service identity shall take the form of either a SIP URI (see IETF RFC 3261 [26]) or a Tel URI (see IETF 
RFC 3966 [45]). A public service identity identifies a service, or a specific resource created for a service on an 
application server. The domain part is pre-defmed by the IMS operators and the IMS system provides the flexibility to 
dynamically create the user part of the PSIs. 

The PSIs are stored in the HSS either as a distinct PSI or as a wildcarded PSI. A distinct PSI contains the PSI that is 
used in routing , whilst a wildcarded PSI represents a collection of PSIs. Wildcarded PSIs enable optimisation of the 
operation and maintenance of the nodes. A wildcarded PSI consists of a delimited regular expression located either in 
the userinfo portion of the SIP URI or in the telephone-subscriber portion of the Tel URI. The regular expression in the 
wildcarded PSI shall take the form of Extended Regular Expressions (ERE) as defined in chapter 9 in IEEE 1003.1- 
2004 Part 1 [60]. The delimiter shall be the exclamation mark character ("!"). If more than two exclamation mark 
characters are present in the userinfo portion or telephone-subscriber portion of a wildcarded PSI then the outside pair 
of exclamation mark characters is regarded as the pair of delimiters (i.e. no exclamation mark characters are allowed to 
be present in the fixed parts of the userinfo portion or telephone-subscriber portion). 

When stored in the HSS, the wildcarded PSI shall include the delimiter character to indicate the extent of the part of the 
PSI that is wildcarded. It is used to separate the regular expression from the fixed part of the wildcarded PSI. 

Example: The following PSI could be stored in the HSS - "sip:chatlist!.*!@example.com". 

When used on an interface, the exclamation mark characters within a PSI shall not be interpreted as delimiter.. 

Example: The following PSIs communicated in interface messages to the HSS will match to the wildcarded PSI of 
"sip:chatlist!.*! ©example. com" stored in the HSS: 

sip:chatlistl ©example. com 

sip:chatlist2 ©example. com 

sip:chatlist42@example.com 

sip:chatlistAbC ©example. com 

sip:chatlist!l ©example.com 

Note that sip:chatlistl ©example.com and sip:chatlist! 1 ©example.com are regarded different specific PSIs, both 
matching the wildcarded PSI sip:chatlist!.*! ©example.com. 

When used by an application server to identify a specific resource (e.g. a chat session) over Inter Operator Network to 
Network Interface (II-NNI), the PSI should be a SIP URI without including a port number. 

NOTE: Based on local configuration policy, a PSI can be routed over Inter Operator Network to Network 

Interface (II-NNI). Details of this routing are operator specific and out of scope of this specification. 



13.5A Private Service Identity 



The Private Service Identity is applicable to a PSI user and is similar to a Private User Identity in the form of a Network 
Access Identifier (NAI), which is defined in IETF RFC 4282 [53]. The Private Service Identity is operator defined and 
although not operationally used for registration, authorisation and authentication in the same way as Private User 
Identity, it enables Public Service Identities to be associated to a Private Service Identity which is required for 
compatibility with the Cx procedures. 



13.6 Anonymous User Identity 



The Anonymous User Identity shall take the form of a SIP URI (see IETF RFC 3261 [26]). A SIP URI for an 
Anonymous User Identity shall take the form "sip:user©domain". The user part shall be the string "anonymous" and the 
domain part shall be the string "anonymous.invalid". The full SIP URI for Anonymous User Identity is thus: 

" sip: anonymous © anonymous . invalid" 
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For more information on the Anonymous User Identity and when it is used, see 3GPP TS 29.163 [63]. 



13.7 Unavailable User Identity 



The Unavailable User Identity shall take the form of a SIP URI (see IETF RFC 3261 [26]). A SIP URI for an 
Unavailable User Identity shall take the form "sip:user@domain". The user part shall be the string "unavailable" and the 
domain part shall be the string "unknown.invalid". The full SIP URI for Unavailable User Identity is thus: 

" sip : unavailable @ unknown, invalid" 

For more information on the Unavailable User Identity and when it is used, see 3GPP TS 29.163 [63]. 

13.8 Instance-ID 

An instance-id is a SIP Contact header parameter that uniquely identifies the SIP UA performing a registration. 

When an IMEI is available, the instance-id shall take the form of a IMEI URN (see draft-montemurro-gsma-imei-urn 
[79]). The format of the instance-id shall take the form "urn:gsma:imei:<gsma-specifier-defined-substring>" where by 
the the gsma-specifier-defmed-substring shall be the IMEI encoded as defined in draft-montemurro-gsma-imei-urn [79]. 
The optional <gsma-specifier-defmed-param> parameters shall not be included in the instance-id. An example of such 
an instance-id is as follows: 

EXAMPLE: urn:gsma:imei:90420156-025763-0 

If no IMEI is available, the instance-id shall take the form of a string representation of a UUID as a URN as defined in 
IETF RFC 4122 [80]. An example of such an instance-id is as follows: 

EXAMPLE: urn:uuid:f81d4fae-7dec-l Id0-a765-00a0c91e6bf6 

For more information on the instance-id and when it is used, see 3GPP TS 24.229 [81]. 

13.9 XCAP Root URI 

1 3.9.1 XCAP Root URI on Ut interface 

13.9.1.1 General 

XCAP Root URI is an HTTP URI that represents the XCAP Root. Although a vaUd URI, the XCAP Root URI does not 
correspond to an actual resource. 

13.9.1.2 Format of XCAP Root URI 

The XCAP Root URI, as defined in IETF RFC 4825 [94], is an HTTP URI that should have the following format: 

"http://xcap.<domain>" 
in which "<domain>" identifies the domain hosting the XCAP server. 

NOTE 1 : The XCAP Root URI does not contain a port portion or an abs path portion of a standard HTTP URI. 

If a preconfigured or provisioned XCAP Root URI is available then the UE shall use it. When a preconfigured or 
provisioned XCAP Root URI does not exist then the UE shall create the XCAP Root URI as follows: 

• The first label shall be "xcap". 

• The next label(s) shall identify the home network as follows: 

1. When the UE has an ISIM, the domain name from the IMPI shall be used (see 3GPP TS 31.103 [93]) as 
follows: 
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a. if the last two labels of the domain name from the IMPI are "3gppnetwork.org": 

i. the next labels shall be all labels of the domain name from the IMPI apart from the last two labels; and 
ii. the last three labels shall be "pub.3gppnetwork.org"; 

b. if the last two labels of the domain name from the IMPI are other than the "3gppnetwork.org": 

i. the next labels shall be all labels of the domain name from the IMPI; 

2. When the UE has a USIM and does not have ISIM, the home network shall be 

"ims.mnc<MNC>.mcc<MCC>.pub. 3gppnetwork.org" where <MNC> and <MCC> shall be derived from the 
components of the IMSI defined in subclause 2.2. If there are only two significant digits in the MNC, one "0" 
digit shall be inserted at the left side to fill the 3 digits coding of MNC in the FQDN of XCAP Root URL 

As an example for the case when the UE has ISIM, where the IMPI is "user@operator.com", the overall XCAP Root 
URI used by the UE would be: 

"http://xcap.operator.com". 

As an example for the case when the UE has ISIM, where the IMPI is 
"234150999999999@ims.mnc015.mcc234.3gppnetwork.org", the overall XCAP Root URI used by the UE would be: 

"xcap.ims.mnc015.mcc234.pub.3gppnetwork.org". 

As an example for the case when the UE has USIM and does not have ISIM, where the MCC is 345 and the MNC is 12, 
the overall XCAP Root URI created and used by the UE would be: 

"xcap.ims.mnc012.mcc345.pub.3gppnetwork.org" 



14 Numbering, addressing and identification for 3GPP 
System to WLAN Interworking 

14.1 Introduction 

This clause describes the format of the parameters needed to access the 3GPP system supporting the WLAN 
interworking. For further information on the use of the parameters see 3GPP TS 24.234 [48]. For more information on 
the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document. 

14.2 Home network realm 

The home network realm shall be in the form of an Internet domain name, e.g. operator.com, as specified in 
RFC 1035 [19]. 

When attempting to authenticate within WLAN access, the WLAN UE shall derive the home network domain name 
from the IMSI as described in the following steps: 

1 . take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 3 1 . 102 [27], 3GPP 
TS 5 1 .01 1 [66]) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the 
beginning; 

2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>. 3gppnetwork.org" domain 
name; 

3. add the label "wlan." to the beginning of the domain name. 
An example of a WLAN NAI realm is: 

IMSI in use: 234150999999999; 
Where: 
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MCC = 234; 

MNC = 15; 

MSIN = 0999999999 

Which gives the home network domain name: wlan.mnc015.mcc234.3gppnetwork.org. 

NOTE: If it is not possible for the WLAN UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted 
and the length of MNC in the IMSI is not available in the "Administrative data" data file), it is 
implementation dependent how the WLAN UE determines the length of the MNC (2 or 3 digits). 

14.3 RootNAI 

The Root NAl shall take the form of a NAI, and shall have the form username@realm as specified in clause 2.1 of IETF 
RFC 4282 [53]. 

The username part format of the Root NAI shall comply with IETF RFC 4187 [50] when EAP AKA authentication is 
used and with IETF RFC 4186 [51], when EAP SIM authentication is used. 

When the username part includes the IMSI, the Root NAI shall be built according to the following steps: 

1. Generate an identity conforming to NAI format from IMSI as defined in EAP SIM [51] and EAP AKA [50] as 
appropriate; 

2. Convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in subclause 14.2. 

The result will be a root NAI of the form: 

"0<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org", for EAP AKA authentication and 
"l<IMSI>@wlan.mnc<MNC>.mcc<MCC>.3gppnetwork.org", for EAP SIM authentication 

For example, for EAP AKA authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the root NAI 
then takes the form 0234150999999999@wlan.mnc015.mcc234.3gppnetwork.org. 

14.4 Decorated NAI 

The Decorated NAI shall take the form of a NAI and shall have the form 'homerealm!username@otherrealm' as 
specified in clause 2.7 of the IETF RFC 4282 [53]. 

The realm part of Decorated NAI consists of 'otherrealm', see the IETF draft 2486-bisRFC 4282 [53]. 'Homerealm' is 
the realm as specified in clause 14.2, using the HPLMN ID ('homeMCC + 'homeMNC)'. 'Otherrealm' is the realm built 
using the PLMN ID (visitedMCC + visited MNC) of the PLMN selected as a result of WLAN PLMN selection (see 
3GPP TS 24.234 [48]). 

The username part format of the Root NAI shall comply with IETF RFC 4187 [50] when EAP AKA authentication is 
used and with IETF RFC 4186 [51], when EAP SIM authentication is used. 

When the username part of Decorated NAI includes the IMSI, it shall be built following the same steps specified for 
Root NAI in clause 14.3. 

The result will be a decorated NAI of the form: 

" wlan. mnc<homeMNC> . mcc<homeMCC> . 3 gppnetwork.org 

!0<IMSI>@wlan.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org", for EAP AKA authentication and " 
wlan. mnc<homeMNC>.mcc<homeMCC>. 3gppnetwork.org 
!l<IMSI>@wlan.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org ", for EAP SIM authentication 

For example, for EAP AKA authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15) and the PLMN 

ID of the Selected PLMN is MCC = 610, MNC = 71 then the Decorated NAI takes the form 

wlan. mnc015. mcc234.3gppnetwork.org 10234150999999999 @ wlan. mnc071.mcc610.3gppnetwork.org. 
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NOTE: the 'otherrealm' specified in the present document is resolved by the WLAN AN. If the WLAN AN does 
not have access to the GRX, then the WLAN AN should resolve the realm by other means e.g. static 
look-up table, private local DNS server acting as an authoritative name server for that sub-domain. 

14.4A Fast Re-authentication NAI 

The Fast Re-authentication NAI in both EAP-SIM and EAP-AKA shall take the form of a NAI as specified in clause 
2. 1 of IETF RFC 4282 [53]. If the 3GPP AAA server does not return a complete NAI, the Fast Re-authentication NAI 
shall consist of the username part of the fast re-authentication identity as returned from the 3GPP AAA server and the 
same realm as used in the permanent user identity. If the 3GPP AAA server returns a complete NAI as the re- 
authentication identity, then this NAI shall be used. The username part of the fast re-authentication identity shall be 
decorated as described in 14.4 if the Selected PLMN is different from the HPLMN. 

NOTE: The permanent user identity is either the root or decorated NAI as defined in clauses 14.3 and 14.4. 

EXAMPLE 1 : If the fast re-authentication identity returned by the 3GPP AAA Server is 458405627015 and the IMSI 
is 234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case when NAI decoration is 
not used takes the form: 4584056270I5@wlan.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 2: If the fast re-authentication identity returned by the 3GPP AAA Server is 

"458405627015@aaal.wlan.mnc015.mcc234.3gppnetwork.org" and the IMSI is 234150999999999 (MCC = 234, 
MNC = 15), the Fast Re-authentication NAI for the case when NAI decoration is not used takes the form: 
458405627015@aaal.wlan.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 3: If the fast re-authentication identity returned by the 3GPP AAA Server is 458405627015 and the IMSI 
is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is MCC = 610, MNC = 71, 
the Fast Re-authentication NAI takes the form: wlan.mnc015.mcc234.3gppnetwork.org 
!458405627015@wlan.mnc071.mcc610.3gppnetwork.org 



14.5 Temporary identities 



The Temporary identities (Pseudonyms and re-authentication identities) shall take the form of a NAI username as 
specified in clause 2.1 of the IETF RFC 4282 [53]. 

Temporary identity shall be generated as specified in subclause 6.4.1 of 3GPPTS 33.234 [55]. This part of the 
temporary identity shall follow the UTF-8 transformation format specified in IETF RFC 2279 [54] except for the 
following reserved hexadecimal octet value: 

FF. 

When the temporary identity username is coded with FF, this reserved value is used to indicate the special case when no 
valid temporary identity exists in the WLAN UE (see 3GPP TS 24.234 [48]). The network shall not allocate a 
temporary identity with the whole username coded with the reserved hexadecimal value FF. 

For EAP-AKA authentication, the username portion of the pseudonym identity shall be prepended with the single digit 
"2" and the username portion of the fast re-authentication identity shall be prepended with the single digit "4" as 
specified in sub-clause 4.1.1.7 of IETF RFC 4187 [50]. 

For EAP-SIM authentication, the username portion of the pseudonym identity shall be prepended with the single digit 
"3" and the username portion of the fast re-authentication identity shall be prepended with the single digit "5" as 
specified in sub-clause 4.2.1.7 of IETF RFC 4186 [51]. 

14.6 Alternative NAI 

The Alternative NAI shall take the form of a NAI, i.e. 'any_username@ REALM' as specified of IETF RFC 4282 [53]. 
The Alternative NAI shall not be routable from any AAA server. 

The Alternative NAI shall contain a username part which is not derived from the IMSI. The username part shall not be a 
null string. 

The REALM part of the NAI shall be 'unreachable.3gppnetwork.org'. 
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The result shall be an NAI in the form of: 
"<any_non_null_string> ©unreachable. 3gppnetwork.org" 

14.7 W-APN 

The W-APN is composed of two parts as follows: 

The W-APN Network Identifier; this defines to which external network the PDG is connected. 

- The W-APN Operator Identifier; this defines in which PLMN the PDG serving the W-APN is located. 

The W-APN Operator Identifier is placed after the W-APN Network Identifier. The W-APN consisting of both the 
Network Identifier and Operator Identifier corresponds to a FQDN of a PDG; the W-APN has, after encoding as defined 
in the paragraph below, a maximum length of 100 octets. 

The encoding of the W-APN shall follow the Name Syntax defined in IETF RFC 2181 [18], IETF RFC 1035 [19] and 
IETF RFC 1 123 [20]. The W-APN consists of one or more labels. Each label is coded as a one octet length field 
followed by that number of octets coded as 8 bit ASCII characters. Following IETF RFC 1035 [19] the labels shall 
consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following IETF RFC 1 123 [20], 
the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not 
significant. The W-APN is not terminated by a length byte of zero. 

For the purpose of presentation, a W-APN is usually displayed as a string in which the labels are separated by dots (e.g. 
"Label l.Label2.Label3"). 

The W-APN for the support of IMS Emergency calls shall take the form of a common, reserved Network Identifier 
described in subclause 14.7.1 together with the usual W-APN Operator Identifier as described in subclause 14.7.2. 

1 4.7. 1 Format of W-APN Network Identifier 

The W-APN Network Identifier follows the format defined for APNs in subclause 9.1.1. In addition to what has been 
defined in subclause 9.1.1 the W-APN Network Identifier shall not contain "w-apn." and not end in ".3gppnetwork.org". 

A W-APN Network Identifier may be used to access a service associated with a PDG. This may be achieved by 
defining: 



a W-APN which corresponds to a FQDN of a PDG, and which is locally interpreted by the PDG as a request for 
a specific service, or 

a W-APN Network Identifier consisting of 3 or more labels and starting with a Reserved Service Label, or a W- 
APN Network Identifier consisting of a Reserved Service Label alone, which indicates a PDG by the nature of 
the requested service. Reserved Service Labels and the corresponding services they stand for shall be agreed 
between operators who have WLAN roaming agreements. 

The W-APN Network Identifier for the support of IMS Emergency calls shall take the form of a common, reserved 
Network Identifier of the form "sos". 

As an example, the W-APN for MCC 345 and MNC 12 is coded in the DNS as: 

"sos.w-apn.mnc012.mcc345.pub.3gppnetwork.org". 

where "sos" is the W-APN Network Identifier and " mnc012.mcc345.pub.3gppnetwork.org " is the W-APN Operator 
Identifier. 

1 4.7.2 Format of W-APN Operator Identifier 

The W-APN Operator Identifier is composed of six labels. The last three labels shall be "pub.3gppnetwork.org". The 
second and third labels together shall uniquely identify the PLMN. The first label distinguishes the domain name as a 
W-APN. 
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For each operator, there is a default W-APN Operator Identifier (i.e. domain name). This default W-APN Operator 
Identifier is derived from the IMSI as follows: 

"w-apn.mnc<MNC>.mcc<MCC>.pub. 3gppnetwork.org" 

where: 

"mnc" and "mcc" serve as invariable identifiers for the following digits. 

<MNC> and <MCC> are derived from the components of the IMSI defined in subclause 2.2. 

Alternatively, the default W-APN Operator Identifier is derived using the MNC and MCC of the VPLMN. See 3GPP 
TS 24.234 [48] for more information. 

The default W-APN Operator Identifier is used in both non-roaming and roaming situations when attempting to 
translate a W-APN consisting only of a Network Identifier into the IP address of the PDG in the HPLMN. 

In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the 
"w-apn.mnc<MNC>.mcc<MCC>.pub. 3gppnetwork.org" format of the W-APN OI shall be: 

- <MNC> = 3 digits 

- <MCC> = 3 digits 

If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding 
of MNC in the W-APN OI. 



As an example, the W-APN OI for MCC 345 and MNC 12 is coded in the DNS as: 
"w-apn.mnc012.mcc345.pub.3gppnetwork.org". 

1 4.7.3 Alternative Format of W-APN Operator Identifier 

For situations when the PDG serving the W-APN is located in such network that is not part of the GRX (i.e. the 
Interoperator IP backbone), the default Operator Identifier described in sub-clause 14.7.2 is not available for use. This 
restriction originates from the '.3gppnetwork.org' domain, which is only available in GRX DNS for actual use. Thus an 
alternative format of W-APN Operator Identifier is required for this case. 

The Alternative W-APN Operator Identifiers shall be constructed as follows: 

"w-apn.<valid operator"s REALM>" 

where: 

<valid operator" s REALM> corresponds to REALM names owned by the operator hosting the PDG serving the 
desired W-APN. 

REALM names are required to be unique, and are piggybacked on the administration of the Public Internet DNS 
namespace. REALM names may also belong to the operator of the VPLMN. 



As an example, the W-APN OI for the Operator REALM "notareal.com" is coded in the Public Internet DNS as: 
"w-apn. notareal.com". 

14.8 Emergency Realm and Emergency NAI for Emergency Cases 

The emergency realm shall be of the form of a home network realm as described in clause 14.2 prefixed with the label 
"sos." at the beginning of the domain name. 

An example of a WLAN emergency NAI realm is: 

IMSI in use: 234150999999999; 
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Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999 

Which gives the home network domain name: sos.wlan.mnc015.mcc234.3gppnetwork.org. 

The NAI for emergency cases shall be of the form as specified in subclauses 14.3 and 14.4, with the addition of the 
emergency realm as described above for PLMNs where the emergency realm is supported. 

When UE is using I-WLAN as the access network for IMS emergency calls and IMSI is not available, the Emergency 
NAI shall be an NAI compliant with IETF RFC 4282 [53] consisting of username and realm, either constructed with 
IMEl or MAC address, as specified in 3GPP TS 33.234 [55]. The exact format shall be: 

imei<lMEl> @ sos . wlan. mnc< visitedMNC> . mcc<visitedMCC> .3gppnetwork.org 

or if IMEl is not available, 

mac<MAC>@sos.wlan.mnc<visitedMNC>.mcc<visitedMCC>. 3gppnetwork.org 

The realm part of the above NAI consists of the realm built using the PLMN ID (visitedMCC + visitedMNC) of the 
PLMN selected as a result of the network selection procedure, as specified in section 5.2.5.4 of the 3GPP TS 24.234 
[48]. 

The MNC and MCC shall be with 3 digits coded. If there are only 2 significant digits in the MNC, one "0" digit shall be 
inserted at the left side to fill the 3 digits coding of MNC in the realm of the NAI. 

For example, if the IMEl is 219551288888888, and the selected PLMN is with MCC 345 and MNC 12, the Emergency 
NAI then takes the form of imei219551288888888@ sos.wlan.mnc012.mcc345.3gppnetwork.org. 

For example, if the MAC address is 44-45-53-54-00-AB, and the selected PLMN is with MCC 345 and MNC 12, the 
Emergency NAI then takes the form of mac4445535400AB@ sos.wlan.mnc012.mcc345.3gppnetwork.org, where the 
MAC address is represented in hexadecimal format without separators. 

15 Identification of IVIultimedia Broadcast/IVIulticast 
Service 

15.1 Introduction 

This clause describes the format of the parameters needed to access the Multimedia Broadcast/Multicast service. For 
further information on the use of the parameters see 3GPP TS 23.246 [52]. 



15.2 Structure of TMGI 



Temporary Mobile Group Identity (TMGI) is used within MBMS to uniquely identify Multicast and Broadcast bearer 

services. 

TMGI is composed as shown in figure 15.2.1. 
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Figure 15.2.1 : Structure of TMGI 

The TMGI is composed of three parts: 

1) MBMS Service ID consisting of three octets. MBMS Service ID consists of a 6-digit fixed-length hexadecimal 
number between 000000 and FFFFFF. MBMS Service ID uniquely identifies an MBMS bearer service within a 
PLMN. 

2) Mobile Country Code (MCC) consisting of three digits. The MCC identifies uniquely the country of domicile of 
the BM-SC; 

3) Mobile Network Code (MNC) consisting of two or three digits (depending on the assignment to the PLMN by its 
national numbering authority). The MNC identifies the PLMN which the BM-SC belongs to. For more 
information on the use of the TMGI, see 3GPP TS 23.246 [52]. 

1 5.3 Structure of MBMS SAI 

The MBMS Service Area (MBMS SA) is defined in 3GPP TS 23.246 [52]. It comprises of one or more MBMS Service 
Area Identities (MBMS SAIs), in any case each MBMS SA shall not include more than 256 MBMS SAIs. An MBMS 
SAI shall identify a group of cells within a PLMN, that is independent of the associated Location/Routing/Service Area 
and the physical location of the cell(s). A cell shall be able to belong to one or more MBMS S As, and therefore is 
addressable by one or more MBMS SAIs. 

The MBMS SAI shall be a decimal number between and 65,535 (inclusive). The value shall have special meaning; 
it denotes the whole PLMN as the MBMS Service Area and it shall indicate to a receiving RNC/BSS that all cells 
reachable by that RNC/BSS are part of the MBMS Service Area. 

With the exception of the specific MBMS Service Ares Identity with value 0, the MBMS Service Area Identity shall be 
unique within a PLMN and shall be defined in such a way that all the corresponding cells are MBMS capable. 

15.4 Home Network Realm 

The home network realm shall be in the form of an Internet domain name, e.g. operator.com, as specified in IETF 
RFC 1035 [19]. 

During the MBMS service activation in roaming scenario, the BM-SC in the visted network shall derive the home 
network domain name from the IMSI as described in the following steps: 

1. Take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27], 3GPP 
TS 5 1 .01 1 [66]) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the 
beginning; 

2. Use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.3gppnetwork.org" realm 
name; 

3. Add the label "mbms." to the beginning of the realm name. 
An example of a home realm used in the MBMS roaming case is: 

IMSI in use: 234150999999999; 
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Where: 

MCC = 234; 
MNC = 15; 
MSIN = 0999999999 
Which gives the home network realm: mbms.mnc015.mcc234.3gppnetwork.org. 

16 Numbering, addressing and identification within the 
GAA subsystem 

16.1 Introduction 

This clause describes the format of the parameters needed to access the GAA system. For further information on the use 
of the parameters see 3GPP TS 33.221 [58]. For more information on the ".3gppnetwork.org" domain name and its 
applicability, see Annex D of the present document. 

16.2 BSF address 

The Bootstrapping Server Function (BSF) address is in the form of a Fully Qualified Domain Name as defined in IETF 
RFC 1035 [19]. 

For 3GPP systems, the UE shall discover the BSF address from the identity information related to the UlCC application 
that is used during the bootstrapping procedure i.e. IMSl for USIM, or IMPl for ISIM, in the following way: 

In the case where the USIM is used in bootstrapping, the BSF address shall be derived as follows: 

1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27]) 
and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the 
beginning; 

2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.pub. 3gppnetwork.org" 
domain name; 

3. add the label "bsf." to the beginning of the domain. 

Example 1: If IMSI in use is "234150999999999", where MCC=234, MNC=15, and MSIN=0999999999, 

the BSF address would be "bsfmnc015.mcc234.pub.3gppnetwork.org". 

In the case where ISIM is used in bootstrapping, the BSF address shall be derived as follows: 

1 . extract the domain name from the IMPl; 

2. if the last two labels of the domain name extracted from the IMPl are "3gppnetwork.org": 

a. the first label is "bsf"; 

b. the next labels are all labels of the domain name extracted from the IMPl apart from the last two 
labels; and 

c. the last three labels are "pub.3gppnetwork.org"; 

Example 2: If the IMPl in use is "234150999999999@ims.mnc015.mcc234.3gppnetwork.org", the BSF 

address would be "bsf.ims.mnc015.mcc234.pub.3gppnetwork.org". 

3. if the last two labels of the domain name extracted from the IMPl are other than the "3gppnetwork.org": 
a. add the label "bsf." to the beginning of the domain. 
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Example 3: If the IMPI in use is "user@operator.com", the BSF address would be "bsf.operator.com ". 

17 Numbering, addressing and identification within the 
Generic Access Network 

17.1 Introduction 

This clause describes the format of the parameters needed to access the Generic Access Network (GAN). For further 
information on the use of the parameters and GAN in general, see 3GPP TS 43.318 [61] and 3GPP TS 44.318 [62]. For 
more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document. 

1 7.2 Network Access Identifiers 

1 7.2.1 Home network realm 

The home network realm shall be in the form of an Internet domain name, e.g. operator.com, as specified in IETF 
RFC 1035 [19]. 

The UE shall derive the home network realm from the IMSI as described in the following steps: 

1 . take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 3 1 . 102 [27], 3GPP 
TS 5 1 .01 1 [66]) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the 
beginning; 

2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>. 3gppnetwork.org" network 
realm; 

3. add the label "gan." to the beginning of the network realm. 
An example of a home network realm is: 

IMSI in use: 234150999999999; 

Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999, 

Which gives the home network realm: gan.mnc015.mcc234.3gppnetwork.org. 

NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the 
length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation 
dependent how the UE determines the length of the MNC (2 or 3 digits). 

1 7.2.2 Full Authentication NAI 

The Full Authentication NAI in both EAP-SIM and EAP-AKA shall take the form of an NAI as specified in clause 2. 1 
of IETF RFC 4282 [53]. The format of the Full Authentication NAI shall comply with IETF RFC 4187 [50] when 
EAP-AKA authentication is used and with IETF RFC 4186 [51], when EAP-SIM authentication is used. The realm used 
shall be a home network realm as defined in sub-clause 17.2.1. 

The result will therefore be an identity of the form: 

"0<IMSI>@gan.mnc<MNC>.mcc<MCC>.3gppnetwork.org", for EAP-AKA authentication and 
" l<IMSI>@gan.mnc<MNC>.mcc<MCC>.3gppnetwork.org", for EAP-SIM authentication 
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EXAMPLE 1 : For EAP AKA authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Full 
Authentication NAl takes the form 0234150999999999@gan.mnc015.mcc234.3gppnetwork.org. 

EXAMPLE 2: For EAP SIM authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the Full 
Authentication NAI takes the form 1234150999999999@gan.mnc015.mcc234.3gppnetwork.org. 

1 7.2.3 Fast Re-authentication NAI 

The Fast Re-authentication NAI in both EAP-SIM and EAP-AKA shall take the form of an NAI as specified in clause 
2.1 of IETF RFC 4282 [53]. The UE shall use the re-authentication identity received during the previous EAP-SIM or 
EAP-AKA authentication procedure. If such an NAI contains a realm part then the UE should not modify it, otherwise 
it shall use a home network realm as defined in sub clause 17.2.1. 

The result will therefore be an identity of the form: 

"<re-authentication_ID_username>@<re-authentication_ID_realm> for both EAP-SIM and EAP-AKA authentication 
when a realm is present in the re-authentication identity received during the previous EAP-SIM or EAP-AKA 
authentication procedure and 

"<re-authentication_ID_username>@gan.mnc<MNC>.mcc<MCC>. 3gppnetwork.org", for both EAP-SIM and 
EAP-AKA authentication when a realm is not present in the re-authentication identity received during the previous 
EAP-SIM or EAP-AKA authentication procedure. 

EXAMPLE 1 : If the re-authentication identity is "12345" and the IMSI is 234150999999999 (MCC = 234, MNC 
= 15), the Fast Re-authentication NAI takes the form 
12345@gan.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 2: If the re-authentication identity is "12345@aaal.gan.mnc015.mcc234.3gppnetwork.org", the Fast 
Re-authentication NAI takes the form 12345@aaal.gan.mnc015.mcc234.3gppnetwork.org 

17.3 Node Identifiers 

1 7.3.1 Home network domain name 

The home network domain name shall be in the form of an Internet domain name, e.g. operator.com, as specified in 
IETF RFC 1035 [19]. 

The UE shall derive the home network domain name from the IMSI as described in the following steps: 

1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27], 3GPP 
TS 5 1 .01 1 [66]) and separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the 
beginning; 

2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>.pub. 3gppnetwork.org" domain 
name; 

3. add the label "gan." to the beginning of the domain name. 
An example of a home network domain name is: 

IMSI in use: 234150999999999; 
Where: 

MCC = 234; 
MNC = 15; 
MSIN = 0999999999, 
Which gives the home network domain name: gan.mnc015.mcc234.pub.3gppnetwork.org. 
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NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the 
length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation 
dependent how the UE determines the length of the MNC (2 or 3 digits). 

1 7.3.2 Provisioning GANC-SEGW identifier 

The Provisioning GANC-SEGW identifier shall take the form of a fully qualified domain name (FQDN) as specified in 
IETF RFC 1035 [19]. If the (U)SIM is not provisioned with the FQDN or IP address of the Provisioning 
GANC-SEGW, the UE derives an FQDN from the IMSI to identify the Provisioning GANC-SEGW. The UE shall 
derive such an FQDN as follows: 

1. create a domain name as specified in 17.3.1; 

2. add the label "psegw." to the beginning of the domain name. 
An example of an FQDN for a Provisioning GANC-SEGW is: 

IMSI in use: 234150999999999; 

Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999, 

Which gives the FQDN: psegw.gan.mnc015.mcc234.pub.3gppnetwork.org. 

NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the 
length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation 
dependent how the UE determines the length of the MNC (2 or 3 digits). 

17.3.3 Provisioning GANG identifier 

The Provisioning GANC identifier shall take the form of a fully qualified domain name (FQDN) as specified in IETF 
RFC 1035 [19]. If the (U)SIM is not provisioned with the FQDN or IP address of the Provisioning GANC, the UE 
derives an FQDN from the IMSI to identify the Provisioning GANC. The UE shall derive such an FQDN as follows: 

1. create a domain name as specified in 17.3.1; 

2. add the label "pganc." to the beginning of the domain name. 
An example of an FQDN for a Provisioning GANC is: 

IMSI in use: 234150999999999; 

Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999, 

Which gives the FQDN: pganc.gan.mnc015.mcc234.pub.3gppnetwork.org. 

NOTE: If it is not possible for the UE to identify whether a 2 or 3 digit MNC is used (e.g. SIM is inserted and the 
length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation 
dependent how the UE determines the length of the MNC (2 or 3 digits). 
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18 Addressing and Identification for IIVIS Service 

Continuity and Single-Radio Voice Call Continuity 

18.1 Introduction 

This clause describes the format of the parameters needed for the support of IMS Service Continuity. For further 
information on the use of the parameters see 3GPP TS 23.237 [71] and also 3GPP TS 23.292 [70]. 

18.2 OS Domain Routeing Number (CSRN) 

A CS Domain Routeing Number (CSRN) is a number that is used to route a call from the IM CN subsystem to the user 
in the CS domain. The structure is as defined in sub-clause 3.4. 

18.3 IP Multimedia Routeing Number (IMRN) 

An IP Multimedia Routeing Number (IMRN) is a routable number that points to the IM CN subsystem. In a roaming 
scenario, the IMRN has the same structure as an international ISDN number (see sub-clause 3.4). The Tel URI format 
of the IMRN (see IETF RFC 3966 [45]) is treated as a PSI (see sub-clause 13.5) within the IM CN subsystem. 

18.4 Session Transfer Number (STN) 

A Session Transfer Number (STN) is a public telecommunication number, as defined by ITU-T Recommendation E.164 
[10] and is used by the UE to request Session Transfer of the media path from PS to CS access. 

18.5 Session Transfer Identifier (STI) 

A Session Transfer Identifier (STI) is a SIP URI or SIP dialogue ID (see IETF RFC 3261 [26] for more information) 
and is used by the UE to request Session Transfer of a media path. 

18.6 Session Transfer Number for Single Radio Voice Call 
Continuity (STN-SR) 

The Session Transfer Number for Single Radio Voice Call Continuity (STN-SR) is a public telecommunication number, 
as defined by ITU-T Recommendation E.164 [10] and is used by the MSC Server to request session transfer of the 
media path from the PS domain to CS domain. 

18.7 Correlation MSISDN 

A Correlation MSISDN (C-MSISDN) is an MSISDN (see sub-clause 3.3) that is used for correlation of sessions at 
access transfer and to route a call from the IM CN subsystem to the same user in the CS domain. The C-MSISDN is 
equal to the MSISDN or the basic MSISDN if multinumbering option is used (see 3GPP TS 23.008 [2], section 2.1.3) 
of the CS access. Any MSISDN of a user that can be used for TS 1 1 (telephony) in the CS domain which is not shared 
by more than one IMS Private Identity in an IMS CN subsystem, can serve as the user's C-MSISDN. 

The C-MSISDN is bound to the IMS Private User Identity and is uniquely assigned per IMSI and IMS Private User 
Identity. 
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19 Numbering, addressing and identification for the 
Evolved Packet Core (EPC) 

19.1 Introduction 

This clause describes the format of the parameters needed to access the Enhanced Packet Core (EPC). For further 
information on the use of the parameters see 3GPP TS 23.401 [72] and 3GPP TS 23.402 [68]. For more information on 
the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present document 



19.2 Home Network Realm/Domain 

The home Network Realm/Domain shall be in the form of an Internet domain name, e.g. operator.com, as specified in 
IETF RFC 1035 [19]. 

The Home Network Realm/Domain shall be in the form of "epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org", where 
"<MNC>" and "<MCC>" fields correspond to the MNC and MCC of the operator"s PLMN. Both the "<MNC>" and 
"<MCC>" fields are 3 digits long. If the MNC of the PLMN is 2 digits, then a zero shall be added at the beginning. 

For example, the Home Network Realm/Domain of an IMSI shall be derived as described in the following steps: 

1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27]) and 
separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning; 

2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>. 3gppnetwork.org" domain 
name; 

3. add the label "epc" to the beginning of the domain name. 
An example of a Home Network Realm/Domain is: 

IMSI in use: 234150999999999; 

Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999; 

Which gives the Home Network Realm/Domain name: epc.mnc015.mcc234.3gppnetwork.org. 

NOTE: If it is not possible for a UE to identify whether a 2 or 3 digit MNC is used (e.g. USIM is inserted and the 
length of MNC in the IMSI is not available in the "Administrative data" data file), it is implementation 
dependent how the UE determines the length of the MNC (2 or 3 digits). 

1 9.3 3GPP access to non-3GPP access interworking 
19.3.1 Introduction 

This subclause describes the format of the UE identification needed to access the 3GPP EPC from both 3GPP and 
non-3GPP accesses. 

The NAI is generated respectively by: 

the S-GW at the S5/S8 reference point; 

the non-3GPP access network or client at the S2a reference point; 
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the ePDG at the S2b reference point; 

the DSMIPv6 cHent at the S2c reference point. 

The NAI shall be generated based on the IMS! or, when UE is performing emergency attach and IMSI is not available 
or not authenticated, on the IMEI (see subclause 19.3.6). 

For further information on the use of the parameters see 3GPP TS 24.234 [48]. 

19.3.2 Root NAI 

The Root NAI shall take the form of an NAI, and shall have the form username@realm as specified in clause 2. 1 of 
IETF RFC 4282 [53]. 

The format of the username part of the Root NAI shall comply with IETF RFC 4187 [50] for use with EAP AKA 
authentication. For EAP- AKA', see IETF RFC 5448 [82], the Root NAI shall comply with IETF RFC 4187 [50] except 
that the username part of the Root NAI shall be prepended with the single digit "6". 

When the username part includes the IMSI, the Root NAI shall be built according to the following steps: 

1. Generate an identity conforming to NAI format from IMSI as defined in EAP AKA [50] as appropriate; 

2. Convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in subclause 19.2. 

3. Prefix domain name with the label of "nai". 
The result will be a root NAI of the form: 

"0<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" for EAP AKA authentication 

"6<IMSI>@nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org" for EAP AKA' authentication 

For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the root NAI then takes the form as 
0234150999999999@nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA authentication, and takes the form as 
6234150999999999@nai.epc.mnc015.mcc234.3gppnetwork.org for EAP AKA" authentication. 

The NAI sent in the Mobile Node Identifier field in PMIPv6 shall not include the digit prepended in front of the IMSI 
that is described above. Consequently the Permanent User Identity assigned by the 3GPP AAA Server when Network 
Based Mobility is used shall not include this digit either. 

19.3.3 Decorated NAI 

The Decorated NAI shall take the form of a NAI and shall have the form 'homerealm!username@otherrealm' as 
specified in clause 2.7 of the IETF RFC 4282 [53]. 

The realm part of Decorated NAI consists of 'otherrealm', see the IETF RFC 4282 [53]. 'Homerealm' is the realm as 
specified in subclause 19. .2, using the HPLMN ID ('homeMCC + 'homeMNC)'. 'Otherrealm' is the realm built using the 
PLMN ID (visitedMCC + visited MNC) of the PLMN selected as a result of the PLMN selection (see 3GPP TS 23.402 
[68]). 

The username part format of the Root NAI shall comply with IETF RFC 4187 [50] for use with EAP AKA. For EAP 
AKA', see IETF RFC 5448 [82], the Root NAI shall comply with IETF RFC 4187 [50] except that the username part of 
the NAI shall be prepended with single digit "6". 

When the username part of Decorated NAI includes the IMSI, it shall be built following the same steps specified for 
Root NAI in subclause 19.3.2. 

The result will be a decorated NAI of the form: 

nai. epc.mnc<homeMNC>.mcc<homeMCC>. 3gppnetwork.org 
!0<IMSI>@nai.epc.mnc<visitedMNC>.mcc<visitedMCC>.3gppnetwork.org for EAP AKA authentication 

or 
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nai.epc.mnc<homeMNC>.mcc<homeMCC>. 3gppnetwork.org 
!6<IMSI>@nai.epc.mnc<visitedMNC>.mcc<visitedMCC>. 3gppnetwork.org for EAP AKA' authentication. 

For example, if the IMSI is 234150999999999 (MCC = 234, MNC = 15) and the PLMN ID of the Selected PLMN is 
MCC = 610, MNC = 71, then the Decorated NAI takes the form either as 

nai.epc.mnc015.mcc234.3gppnetwork.org!0234150999999999@nai. epc.mnc071.mcc610.3gppnetwork.org for EAP 
AKA authentication or 

nai.epc.mnc015.mcc234.3gppnetwork.org!6234150999999999@nai. epc.mnc071.mcc610.3gppnetwork.org for EAP 
AKA' authentication. 

19.3.4 Fast Re-authentication NAI 

The Fast Re-authentication NAI shall take the form of a NAI as specified in clause 2. 1 of IETF RFC 4282 [53]. If the 
3GPP AAA server does not return a complete NAI, the Fast Re-authentication NAI shall consist of the username part of 
the fast re-authentication identity as returned from the 3GPP AAA server and the same realm as used in the permanent 
user identity. If the 3GPP AAA server returns a complete NAI as the re-authentication identity, then this NAI shall be 
used. The username part of the fast re-authentication identity shall be decorated as described in 19.3.3 if the Selected 
PLMN is different from the HPLMN. 

For EAP- AKA authentication, the username portion of the fast re-authentication identity shall be prepended with the 
single digit "4" as specified in sub-clause 4.1.1.7 of IETF RFC 4187 [50]. 

For EAP AKA', see IETF RFC 5448 [82], the Fast Re-authentication NAI shall comply with IETF RFC 4187 [50] 
except that the username part of the NAI shall be prepended with single digit "8". 

NOTE: The permanent user identity is either the Root NAI or Decorated NAI as defined in clauses 19.3.2 and 
19.3.3, respectively. 

EXAMPLE 1 : If the fast re-authentication identity returned by the 3GPP AAA Server is 358405627015 and the 
IMSI is 234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case 
when NAI decoration is not used takes the form: 
358405627015@nai.epc.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 2: If the fast re-authentication identity returned by the 3GPP AAA Server is 

"358405627015@aaal.nai.epc.mnc015.mcc234.3gppnetwork.org" and the IMSI is 
234150999999999 (MCC = 234, MNC = 15), the Fast Re-authentication NAI for the case when 
NAI decoration is not used takes the form: 
358405627015@aaal.nai.epc.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 3: If the fast re-authentication identity returned by the 3GPP AAA Server is 358405627015 and the 
IMSI is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is 
MCC = 610, MNC = 71, the Fast Re-authentication NAI takes the form: 
nai.epc.mnc015.mcc234.3gppnetwork.org 
!358405627015@nai. epc.mnc071.mcc610.3gppnetwork.org. 

19.3.5 Pseudonym Identities 

The pseudonym shall take the form of an NAI, as specified in sub-clause 2.1 of IETF RFC 4282 [53]. 

The pseudonym shall be generated as specified in sub-clause 6.4.1 of 3GPP TS 33.234 [55]. This part of the pseudonym 
shall follow the UTF-8 transformation format specified in IETF RFC 2279 [54] except for the following reserved 
hexadecimal octet value: 

FF 

When the pseudonym username is coded with FF, this reserved value is used to indicate the special case when no valid 
temporary identity exists in the UE (see 3GPP TS 24.234 [48] for more information). The network shall not allocate a 
temporary identity with the whole username coded with the reserved hexadecimal value FF. 
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The username portion of the pseudonym identity shall be prepended with the single digit "2" as specified in sub-clause 
4.1.1.7 of IETF RFC 4187 [50] for EAP-AKA. For BAP AKA', see IETF RFC 5448 [82], the pseudonym NAI shall 
comply with IETF RFC 4187 [50] except that the username part of the NAI shall be prepended with single digit "7". 

NOTE: The permanent user identity is either the Root NAI or Decorated NAI as defined in sub-clauses 19.3.2 and 
19.3.3, respectively. 

EXAMPLE 1 : For EAP AKA, if the pseudonym returned by the 3GPP AAA Server is 258405627015 and the 

IMSI is 234150999999999 (MCC = 234, MNC = 15), the pseudonym NAI for the case when NAI 
decoration is not used takes the form: 258405627015@nai.epc.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 2: For EAP AKA', if the pseudonym returned by the 3GPP AAA Server is 758405627015 and the 

IMSI is 234150999999999 (MCC = 234, MNC = 15), the pseudonym NAI for the case when NAI 
decoration is not used takes the form: 758405627015@nai.epc.mnc015.mcc234.3gppnetwork.org 

EXAMPLE 3: For EAP AKA, if the pseudonym returned by the 3GPP AAA Server is 258405627015 and the 

IMSI is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is 
MCC = 610, MNC = 71, the pseudonym NAI takes the form: 
nai.epc.mnc015.mcc234.3gppnetwork.org! 
258405627015@nai.epc.mnc071.mcc610.3gppnetwork.org 

EXAMPLE 4: For EAP AKA', if the pseudonym returned by the 3GPP AAA Server is 758405627015 and the 

IMSI is 234150999999999 (MCC = 234, MNC = 15), and the PLMN ID of the Selected PLMN is 
MCC = 610, MNC = 71, the pseudonym NAI takes the form: 
nai.epc.mnc015.mcc234.3gppnetwork.org! 
758405627015@nai.epc.mnc071.mcc610.3gppnetwork.org 

1 9.3.6 Emergency NAI for Limited Service State 

This subclause describes the format of the UE identification needed to access the 3GPP EPC from both 3GPP and 
non-3GPP accesses, when UE is performing emergency attach and IMSI is not available or not authenticated. For more 
information, see sections 4.6.1 and 5.2 of 3GPP TS 23.402 [68]. 

The Emergency NAI for Limited Service State shall take the form of an NAI, and shall have the form username ©realm 
as specified in clause 2.1 of IETF RFC 4282 [53]. The exact format shall be: 

imei<IMEI>@ SOS. invalid 

NOTE: The top level domain ".invalid" is a reserved top level domain, as specified in IETF RFC 2606 [64], and 
is used here due to the fact that this NAI never needs to be resolved for routing (as specified in 3GPP TS 
23.402 [68]). 



mac<M AC> @ sos . invalid 

For example, if the IMEI is 219551288888888, the Emergency NAI for Limited Service State then takes the form of 
imei219551288888888@sos.invalid. 

For example, if the MAC address is 44-45-53-54-00-AB, the Emergency NAI for Limited Service State then takes the 
form of mac4445535400AB@sos. invalid , where the MAC address is represented in hexadecimal format without 
separators. 

19.4 Identifiers for Domain Name System procedures 
19.4.1 Introduction 

This clause describes Domain Name System (DNS) related identifiers used by the procedures specified in 3GPP TS 
29.303 [73]. 

The DNS identifiers for APNs for legacy systems (as defined in clause 9), RAIs (as defined in clause C.l, GSNs (as 
defined in clause C.2) and RNCs (as defined in clause C.3) in the present document use the top level domain ".gprs" and 
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have a similar purpose and function as those described below. These clauses are still valid and DNS records based on 
these and the below types of identifiers are expected to coexist in an operator's network for the purpose of backwards 
compatibility and interworking with legacy networks. 

The APN as defined in clause 9 is used also in EPC to identify the access network to be used for a specific PDN 
connection or PDP Context. In addition, the APN Network Identifier (APN-NI) part of the APN as defined in subclause 

9.1.1 of the present document may be used to access a service associated with a PDN-GW or GGSN. This is achieved 
by defining an APN which in addition to being usable to select a PDN-GW or GGSN is locally interpreted by the 
PDN-GW or GGSN as a request for a specific service. 

For DNS procedures defined in 3GPP TS 29.303 [73], an APN-FQDN derived from a given APN is used instead of the 
APN itself as defined in subclause 19.4.2.2. For all other purposes, including communication between EPC nodes and 
to the UE, the APN format defined in clause 9 is used. In order to support backwards compatibility with existing 
GPRS/PS roaming using the Gn/Gp interfaces, the APN as specified in clause 9 of the present document may also be 
used for the DNS procedures as defined in 3GPP TS 23.060 [3]. 

1 9.4.2 Fully Qualified Domain Names (FQDNs) 

19.4.2.1 General 

The encoding of any identifier used as part of a Fully Qualifed Domain Name (FQDN) shall follow the Name Syntax 
defined in IETF RFC 2181 [18], IETF RFC 1035 [19] and IETF RFC 1123 [20]. An FQDN consists of one or more 
labels. Each label is coded as a one octet length field followed by that number of octets coded as 8 bit ASCII characters. 
Following IETF RFC 1035 [19] the labels shall consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and 
the hyphen (-). Following IETF RFC 1 123 [20], the label shall begin and end with either an alphabetic character or a 
digit. The case of alphabetic characters is not significant. Identifiers are not terminated by a length byte of zero. 

NOTE: A length byte of zero is added by the querying entity at the end of the FQDN before interrogating a DNS 
server. 

For the purpose of presentation, identifiers are usually displayed as a string in which the labels are separated by dots 
(e.g. "Labell.Label2.Label3"). 

19.4.2.2 Access Point Name FQDN (APN-FQDN) 
19.4.2.2.1 Structure 

The Access Point Name FQDN (APN-FQDN) is derived from an APN as follows. The APN consists of an APN 
Network Identifier (APN-NI) and an APN Operator Identifier (APN-OI), which are as defined in subclause 9.1.1 and 

9. 1 .2 of the present document. 

If an APN is constructed using the default APN-OI, the APN-FQDN shall be obtained from the APN by inserting the 
labels "apn.epc." between the APN-NI and the default APN - OI, and by replacing the label ".gprs" at the end of the 
default APN-OI with the labels ".3gppnetwork.org". 

EXAMPLEl : For an APN of internet.mnc015.mcc234.gprs, the derived APN-FQDN is 
internet.apn.epc.mnc015.mcc234.3gppnetwork.org 

If an APN is constructed using the APN-OI Replacement field (as defined in 3GPP TS 23.060 [3] and 3GPP TS 23.401 
[72]), the APN-FQDN shall be obtained from the APN by inserting the labels "apn.epc." between the label 
"mnc<MNC>" and its preceding label, and by replacing the label ".gprs" at the end of the APN-OI Replacement field 
with the labels ".3gppnetwork.org". 

EXAMPLE 2: If an APN-OI Replacement field is provincel.mnc015.mcc234.gprs and an APN-NI is internet, the 
derived APN-FQDN is internet, provincel.apn.epc.mnc015.mcc234.3gppnetwork.org 
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19.4.2.2.2 



Void 



19.4.2.2.3 



Void 



19.4.2.2.4 



Void 



1 9.4.2.3 Tracking Area Identity (TAI) 

The Tracking Area Identity (TAI) consists of a Mobile Country Code (MCC), Mobile Network Code (MNC), and 
Tracking Area Code (TAC). It is composed as shown in figure 19.4.2.3.1. 
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Figure 19.4.2.3.1 : Structure of the Tracking Area Identity (TAI) 

The TAI is composed of the following elements: 

- Mobile Country Code (MCC) identifies the country in which the PLMN is located. The value of the MCC is the 
same as the three digit MCC contained in the IMSI; 

- Mobile Network Code (MNC) is a code identifying the PLMN in that country. The value of the MNC is the 
same as the two or three digit MNC contained in the IMSI; 

Tracking Area Code (TAC) is a fixed length code (of 2 octets) identifying a Tracking Area within a PLMN. This 
part of the tracking area identification shall be coded using a full hexadecimal representation. The following are 
reserved hexadecimal values of the TAC: 

- 0000, and 

- FFFE. 

NOTE: The above reserved values are used in some special cases when no valid TAI exists in the MS (see 
3GPP TS 24.301 [90] for more information). 

A subdomain name can be derived from the TAI. This shall be done by adding the label "tac" to the beginning of the 
Home Network Realm/Domain (see subclause 19.2) and encoding the TAC as a sub-domain. This is called the TAJ 
FQDN.. 

The TAI FQDN shall be constructed as follows: 

tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.tac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org 

The TAC is a 16-bit integer. The <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC 
and the <T AC -low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits 
in <TAC-high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding. 

1 9.4.2.4 IVIobility IVianagement Entity (IVIIVIE) 

A Mobility Management Entity (MME) within an operator's network is identified using a MME Group ID (MMEGI), 
and an MME Code (MMEC). 

A subdomain name shall be derived from the MNC and MCC by adding the label "mme" to the beginning of the Home 
Network Realm/Domain (see subclause 19.2). 
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The MME node FQDN shall be constructed as: 

mmec<MMEC>.mmegi<MMEGI>.mme.epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org 
Where <MMEC> and <MMEGI> are the hexadecimal strings of the MMEC and MMEGI. 
An MME pool FQDN shall be constructed as: 

mmegi<MMEGI>.mme.epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org 

1 9.4.2.5 Routing Area Identity (RAI) - EPC 

The Routing Area Identity (RAI) consists of a RAC, LAC, MNC and MCC. 

A subdomain name for use by core network nodes based on RAJ shall be derived from the MNC and MCC by adding 
the label "rac" to the beginning of the Home Network Realm/Domain (see subclause 19.2). 

The RAI FQDN shall be constructed as: 

rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org 

<RAC> and <LAC> shall be Hex coded digits representing the LAC and RAC codes respectively. 

If there are less than 4 significant digits in <RAC> or <LAC>, one or more "0" digit(s) is/are inserted at the left side to 
fill the 4 digit coding. 

Note: Above subdomain is for release 8 core network nodes to allow DNS records other than A/AAAA records. 
The subdomain name in Annex C.2 are still used for existing A/AAAA records for pre-Release 8 nodes 
and are also still used for backward compatibility. 

19.4.2.6 Serving GPRS Support Node (SGSN) within SGSN pool 

A specific SGSN within an operator's network is identified using the RAI FQDN (subclause 19.4.2.5) and the Network 
Resource Identifier (NRI) (see 3GPP TS 23.236 [23]). Such an identifier can be used by a target MME or SGSN node 
to connect to the source SGSN node. 

The SGSN FQDN shall be constructed as: 

nri-sgsn<NRI>.rac<RAC>.lac<LAC>.rac.epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org 

<NRI> shall be Hex coded digits representing the NRI code of the SGSN. 

If there are less than 4 significant digits in < NRI>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 
digit coding. Coding for other fields is the same as in Section 19.4.2.5. 

When a target MME constructs the FQDN of the source SGSN in the case of SGSN pooling, it should derive the NRI 
from the 8-bit MME Code received in the GUTI from the UE. However, if the length of the NRI, e.g., X, which is 
configured in the MME is less than 8 bits, then the MME should use only the most significant X bits of the MME Code 
as the NRI within the SGSN FQDN. 

Note: Above subdomain is for release 8 core network nodes to allow DNS records other than A/AAAA records. 
The subdomain name in Annex C.2 are still used for existing A/AAAA records for pre-Release 8 nodes 
and are also still used for backward compatibility. . 

1 9.4.2.7 Target RNG-ID for U-TRAN 

In the special case of a UTRAN target RNC a possible SGSN that can control that RNC can be identified by RNC-ID. 
This identifier can be used for SRNS relocation with a U-TRAN target RNC. 

A subdomain name for use by core network nodes based on RNC-ID shall be derived from the MNC and MCC by 
adding the label "rnc" to the beginning of the Home Network Realm/Domain (see subclause 19.2). 

The RNC FQDN shall be constructed as: 

rnc<RNC> .rnc. epc . mnc<MNC>. mcc<MCC> . 3gppnetwork. org 
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<RNC> shall be Hex coded digits representing the RNC-ID code of the RNC. 

If there are less than 4 significant digits in <RNC>, one or more "0" digit(s) is/are inserted at the left side to fill the 4 
digit coding. 

NOTE: Above subdomain is for release 8 core network nodes to allow DNS records other than A/AAAA records. 
The subdomain name in Annex C.3 are still used for existing A/AAAA records for pre-Release 8 nodes 
and are still used for backward compatibility. However, RNC-ID in Annex C.3 was originally intended 
for the case where only one SGSN controlled an RNC-ID and gave the SGSN IP address. The usage for 
the above RNC FQDN is potentially broader and can target an SGSN pool. 

19.4.2.8 DNS subdomain for operator usage in EPC 

The EPC nodes DNS subdomain (DNS zone) shall be derived from the MNC and MCC by adding the label "node" to 
the beginning of the Home Network Realm/Domain (see subclause 19.2) and shall be constructed as: 

node. epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org 

This DNS subdomain is formally placed into the operator's control. 3GPP shall never take this DNS subdomain back or 
any zone cut/subdomain within it for any purpose. As a result the operator can safely provision any DNS records it 
chooses under this subdomain without concern about future 3GPP standards encroaching on the DNS names within this 
zone. 

19.4.2.9 ePDG Fully Qualified Domain Name 

The ePDG Fully Qualified Domain Name (ePDG FQDN) contains an Operator Identifier that shall uniquely identify the 
PLMN where the ePDG is located. The ePDG FQDN is composed of seven labels. The last three labels shall be 
"pub.3gppnetwork.org". The third and fourth labels together shall uniquely identify the PLMN. The first two labels 
shall be "epdg.epc". The result of the ePDG FQDN will be: 

"epdg.epc.mnc<MNC>.mcc<MCC>.pub. 3gppnetwork.org" 

In the roaming case, the UE may utilise the services of the VPLMN. In this case, the ePDG FQDN Operator Identifier 
shall be constructed as described above, but using the MNC and MCC of the VPLMN. 

In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the "epdg.epc. 
mnc<MNC>.mcc<MCC> .pub. 3gppnetwork.org" format of the ePDG FQDN Operator Identifier shall be: 

- <MNC> = 3 digits 

- <MCC> = 3 digits 

If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding 
of MNC in the ePDG FQDN. 

As an example, the ePDG FQDN Operator Identifier for MCC 345 and MNC 12 is coded in the DNS as: 

"epdg.epc.mnc012.mcc345.pub.3gppnetwork.org". 

1 9.4.2.1 Global eNodeB-ID for eNodeB 

The Global eNodeB-ID is used to identify eNodeBs globally which is composed of the concatenation of MCC, MNC 
and the eNodeBID. The MCC and MNC are the same as included in the E-UTRAN Cell Global Identifier (ECGI) (see 
subclause 19.6). 

A subdomain name shall be derived from the MNC and MCC by adding the label "enb" to the beginning of the Home 
Network Realm/Domain (see subclause 19.2). 

The Global eNodeB-ID FQDN shall be constructed as: 

enb<eNodeB-ID>. enb. epc.mnc<MNC>.mcc<MCC>. 3gppnetwork.org 

The <eNodeB-ID> shall be coded using a full hexadecimal representation. If there are less than 4 significant digits in < 
eNodeB-ID>, "0" digit(s) shall be inserted at the left side to fill the 4 digit coding. 
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1 9.4.3 Service and Protocol service names for 3GPP 

A list of standardized "service-parms" names is required to identify a "service" as defined in section 6.5 of IETF RFC 
3958 [74]. 

The following table defines the names to be used in the procedures specified in 3GPP TS 29.303 [73]: 
Table 19.4.3.1 : List of 'app-service' and 'app-protocol' names 



Description 


IETF RFC 3958 section 6.5 
'app-service' name 


IETF RFC 3958 section 6.5 
'app-protocol' name 


PGW and interface types supported 
by the PGW 


x-3gpp-pgw 


x-s5-gtp , x-s5-pmip, 

x-s8-gtp , x-s8-pmip, 

x-s2a-pmip, x-s2a-mipv4, x-s2b-pmip, 

x-s2b-gtp, x-s2c-dsmip, x-gn, x-gp 


SGW and interface types supported 
by the SGW 


x-3gpp-sgw 


x-s5-gtp , x-s5-pmip, 
x-s8-gtp , x-s8-pmip, 
x-s11, x-s12, x-s4, 
x-sl-u, x-s2a-pmip, x-s2b-pmip 


GGSN 


x-3gpp-ggsn 


x-gn, x-gp 


SGSN 


x-3gpp-sgsn 


x-gn, x-gp, x-s4,x-s3, x-s16 


IVIIVIE and interface types supported 
by the IVIIVIE 


x-3gpp-mme 


x-s10, x-s11, x-s3, x-s6a, x-sl-mme, 
x-gn, x-gp 


MSG Server 


x-3gpp-msc 


x-sv 



NOTE 1: The formats follow the experimental format as specified in IETF RFC 3958 [74]. For example, to find the 
S8 PMIP interfaces on a PGW the Service Parameter of "3gpp-pgw:x-s8-pmip" would be used as input in 
the procedures defined in IETF RFC 3958 [74]. 

NOTE 2: Currently 'app-service' names identify 3GPP node type and 'app-protocol' identify 3GPP interfaces, which 
differs from more common usage of S-NAPTR where app-protocol is used for transport protocol. Type of 
nodes (i.e PGW, SGW, SGSN, MME, MSC Server etc) and interfaces (i.e. SI 1, S5, S8, Sv, etc.) follow 
the standard names from 3GPP TS 23.401 [72] ,3GPP TS 29.060 [6] and3GPP TS 23.216 [92] with prefix 
"X-" added. 

NOTE 3: x-gn denotes an intra-PLMN interface using GTPvl-C, x-gp denotes a inter-PLMN interface using 
GTPvl-C. 

NOTE 4: The app-service of x-3gpp-pgw with app-protocols x-gn or x-gp identifies the co-located GGSN function 
on a PGW. The app-service of x-3gpp-ggsn with app-protocols x-gn or x-gp identifies a GGSN function 
that is not co-located with a PGW. 

NOTE 5: The app-service of x-3gpp-msc with app-protocol x-sv identifies the MSC Sv interface service. 



19.5 Access Network Identity 



A trusted non-3GPP access network used by the UE to access EPS can be identified using the Access Network Identity. 
The Access Network Identity is used as an input parameter in the EPS security procedures as specified in 3GPP TS 
33.402 [69]. The format and signalling of the parameter between the network and the UE is specified in 3GPP TS 
24.302 [77 and the format and signalling of this parameter between access network and core network is specified in 
3GPPTS 29.273 [78]. 

The encoding of the Access Network Identity shall be specified within 3GPP, but the Access Network Identity 
definition for each non-3GPP access network is under the responsibiUty of the corresponding standardisation 
organisation respectively. 
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19.6 E-UTRAN Cell Identity (ECl) and E-UTRAN Cell Global Identification 
(ECGI) 

The E-UTRAN Cell Global Identification (ECGI) shall be composed of the concatenation of the PLMN Identifier 
(PLMN-Id) and the E-UTRAN Cell Identity (ECI) as shown in figure 19.6.1 and shall be globally unique: 



















MCC 




MNC 




ECI 






< 


E-UTRAN Cell Global 

Identification "^ 





Figure 19.6.1 : Structure of E-UTRAN Cell Global Identification 

The ECI shall be of fixed length of 28 bits and shall be coded using full hexadecimal representation. The exact coding 
of the ECI is the responsibility of each PLMN operator. 

For more details on ECI and ECGI, see 3GPP TS 36.413 [84]. 



20 Addressing and Identification for IIVIS Centralized 
Services 

20.1 Introduction 

This clause describes the format of the parameters needed specifically for IMS Centralized Services (ICS). For further 
information on the use of ICS parameters, see 3GPP TS 23.292 [70]. 

20.2 UE based solution 

In this solution, the UE is provisioned with an ICS specific client that simply reuses IMS registration as defined in 
3GPP TS 23.228 [24]. Therefore, ICS capable UE shall reuse the identities defined in clause 13. 

20.3 Network based solution 

20.3.1 General 

In this solution the MSC Server enhanced for ICS performs a special IMS registration on behalf of the UE. Thus, the 
MSC Server enhanced for ICS shall use a Private User Identity and Temporary Public User Identity that are different to 
those defined in clause 13 (see 3GPP TS 23.292 [70], sub-clause 4.6.2 for more information). Furthermore, the MSC 
Server enhanced for ICS derives a Conference Factory URI that is known to the home IMS. These are defined in the 
following sub-clauses. 

20.3.2 Home network domain name 

The home network domain name shall be in the form of an Internet domain name, e.g. operator.com, as specified in 
IETF RFC 1035 [19]. 

The MSC Server enhanced for ICS shall derive the home network domain name from the subscriber's IMSI as described 
in the following steps: 

1. Take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27]) and 
separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning. 
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2. Use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>. 3gppnetwork.org" domain 
name. 

3. Add the label "ics." to the beginning of the domain. 
An example of a home network domain name is: 

IMSI in use: 234150999999999; 
where: 

- MCC = 234; 

- MNC = 15; and 

- MSIN = 0999999999, 

which gives the home network domain name: ics.mnc015.mcc234.3gppnetwork.org 



20.3.3 Private User Identity 



The Private User Identity shall take the form of an NAI, and shall have the form "username ©realm" as specified in 
clause 2.1 of IETF RFC 4282 [53]. 

The MSC Server enhanced for ICS shall derive the Private User Identity from the subscriber's IMSI as follows: 

1 . Use the whole string of digits as the username part of the private user identity; and 

2. convert the leading digits of the IMSI, i.e. MNC and MCC, into a domain name, as described in sub-clause 
20.3.2. 

The result will be a Private User Identity of the form "<IMSI>@ics.mnc<MNC>.mcc<MCC>. 3gppnetwork.org". For 
example if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the private user identity then takes the form 
234150999999999@ics.mnc015.mcc234.3gppnetwork.org 

20.3.4 Public User Identity 

The Pubhc User Identity shall take the form of a SIP URI (see IETF RFC 3261 [26]), and shall have the form 
" sip: username ©domain" . 

The MSC Server enhanced for ICS shall derive the Public User Identity from the subscriber's IMSI. The Public User 
Identity shall consist of the string "sip:" appended with a username and domain portion equal to the IMSI derived 
Private User Identity described in sub-clause 20.3.3. An example using the same example IMSI from sub-clause 20.3.3 
can be found below: 

EXAMPLE: "sip:234150999999999@ics.mnc015.mcc234.3gppnetwork.org". 

20.3.5 Conference Factory URI 

The Conference Factory URI shall take the form of a SIP URI (see IETF RFC 3261 [26]) with a host portion set to the 
home network domain name as described in subclause 20.3.2 prefixed with "conf- factory.". An example using the same 
example IMSI from sub-clause 20.3.2 can be found below: 

EXAMPLE: "sip:conf-factory.ics. mnc015.mcc234.3gppnetwork.org". 

The user portion of the SIP URI is optional and implementation specific. 
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21 Addressing and Identification for Dual Stack IVIobile 
IPv6 (DSMIPv6) 

21.1 Introduction 

This clause describes the format of the parameters needed by the UE to use Dual Stack Mobile IPv6 (DSMIPv6 as 
specified in 3GPP TS 23.327 [76] and 3GPP TS 23.402 [68]. 

21 .2 Home Agent - Access Point Name (HA-APN) 

21.2.1 General 

The HA-APN is composed of two parts as follows: 

The HA-APN Network Identifier; this defines to which external network the HA is connected. 

- The HA-APN Operator Identifier; this defines in which PLMN the HA serving the HA-APN is located. 

The HA-APN Operator Identifier is placed after the HA-APN Network Identifier. The HA-APN consisting of both the 
Network Identifier and Operator Identifier corresponds to a FQDN of a HA; the HA-APN has, after encoding as defined 
in the paragraph below, a maximum length of 100 octets. 

The encoding of the HA-APN shall follow the Name Syntax defined in IETF RFC 2181 [18], IETF RFC 1035 [19] and 
IETF RFC 1 123 [20]. The HA-APN consists of one or more labels. Each label is coded as a one octet length field 
followed by that number of octets coded as 8 bit ASCII characters. Following IETF RFC 1035 [19] the labels shall 
consist only of the alphabetic characters (A-Z and a-z), digits (0-9) and the hyphen (-). Following IETF RFC 1 123 [20], 
the label shall begin and end with either an alphabetic character or a digit. The case of alphabetic characters is not 
significant. The HA-APN is not terminated by a length byte of zero. 

For the purpose of presentation, a HA-APN is usually displayed as a string in which the labels are separated by dots 
(e.g. "Labell.Label2.Label3"). 

21 .2.2 Format of HA-APN Network Identifier 

The HA-APN Network Identifier follows the format defined for APNs in subclause 9.1.1. In addition to what has been 
defined in subclause 9.1.1 the HA-APN Network Identifier shall not contain "ha-apn." or "w-apn." and not end in 
" .3gppnetwork.org" . 

A HA-APN Network Identifier may be used to access a service associated with a HA. This may be achieved by 
defining: 

a HA-APN which corresponds to a FQDN of a HA, and which is locally interpreted by the HA as a request for a 
specific service, or 

a HA-APN Network Identifier consisting of 3 or more labels and starting with a Reserved Service Label, or a 
HA-APN Network Identifier consisting of a Reserved Service Label alone, which indicates a HA by the nature 
of the requested service. Reserved Service Labels and the corresponding services they stand for shall be agreed 
between operators who have roaming agreements. 

As an example, the HA-APN for MCC 345 and MNC 12 is coded in the DNS as: 

"internet.ha-apn.mnc012.mcc345.pub.3gppnetwork.org". 

where "internet" is the HA-APN Network Identifier and "mnc012.mcc345.pub.3gppnetwork.org " is the HA-APN 
Operator Identifier. 
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21 .2.3 Format of HA-APN Operator Identifier 

The HA-APN Operator Identifier is composed of six labels. The last three labels shall be "pub.3gppnetwork.org". The 
second and third labels together shall uniquely identify the PLMN. The first label distinguishes the domain name as a 
HA-APN. 

For each operator, there is a default HA-APN Operator Identifier (i.e. domain name). This default HA-APN Operator 
Identifier is derived from the IMSI as follows: 

"ha-apn.mnc<MNC>.mcc<MCC>. pub. 3gppnetwork.org" 
where: 

"mnc" and "mcc" serve as invariable identifiers for the following digits. 

<MNC> and <MCC> are derived from the components of the IMSI defined in subclause 2.2. 

Alternatively, the default HA-APN Operator Identifier is derived using the MNC and MCC of the VPLMN. 

In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the 
"ha-apn.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org" format of the HA-APN OI shall be: 

- <MNC> = 3 digits 

- <MCC> = 3 digits 

If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding 
of MNC in the HA-APN OI. 

As an example, the HA-APN OI for MCC 345 and MNC 12 is coded in the DNS as: 

"ha-apn.mnc012.mcc345.pub.3gppnetwork.org". 

22 Addressing and identification for ANDSF 

22.1 Introduction 

This clause describes the format of the parameters needed by the UE to use Access Network Discovery and Selection 
Function (ANDSF) as specified in 3GPP TS 23.402 [68]. 

22.2 ANDSF Server Name (ANDSF-SN) 

22.2.1 General 

ANDSF Server Name (ANDSF-SN) is used by UE to discover ANDSF Server in the network. 

22.2.2 Format of ANDSF-SN 

The ANDSF-SN is composed of six labels. The last three labels shall be "pub.3gppnetwork.org". The second and third 
labels together shall uniquely identify the PLMN. The first label shall be "andsf '. 

The ANDSF-SN is derived from the IMSI or Visited PLMN Identity as follows: 

" andsf mnc<MNC>. mcc<MCC> .pub .3gppnetwork.org " 
where: 

"mnc" and "mcc" serve as invariable identifiers for the following digits. 

When contacting Visited ANDSF (V-ANDSF), the <MNC> and <MCC> shall be derived from the Visited 
PLMN Identity as defined in subclause 12.1. 
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When contacting Home ANDSF (H-ANDSF), the <MNC> and <MCC> shall be derived from the components 
of the IMSI defined in subclause 2.2. 

In order to guarantee inter-PLMN DNS translation, the <MNC> and <MCC> coding used in the 
"andsfmnc<MNC>.mcc<MCC> .pub.3gppnetwork.org" format of the ANDSF-SN shall be: 

- <MNC> = 3 digits 

- <MCC> = 3 digits 

If there are only 2 significant digits in the MNC, one "0" digit shall be inserted at the left side to fill the 3 digits coding 
of MNC in the ANDSF-SN. 

As an example, the ANDSF-SN OI for MCC 345 and MNC 12 is coded in the DNS as: 

"andsfmnc012.mcc345.pub.3gppnetwork.org". 

23 Numbering, addressing and identification for the 
Relay Node OAIVI System 

23.1 Introduction 

This clause describes some information needed to access the Relay Node OAM system as specified in TS 36.300 [91]. 
For more information on the ".3gppnetwork.org" domain name and its applicability, see Annex D of the present 
document. 

23.2 OAM System Realm/Domain 

The OAM system shall be in the form of an Internet domain name, e.g. operator.com, as specified in IETF 
RFC 1035 [19]. 

The OAM System Realm/Domain shall be in the form of "oam.mnc<MNC>.mcc<MCC>. 3gppnetwork.org", where 
"<MNC>" and "<MCC>" fields correspond to the MNC and MCC of the operator"s PLMN. Both the "<MNC>" and 
"<MCC>" fields are 3 digits long. If the MNC of the PLMN is 2 digits, then a zero shall be added at the beginning. 

For example, the OAM System Realm/Domain of an IMSI shall be derived as described in the following steps: 

1. take the first 5 or 6 digits, depending on whether a 2 or 3 digit MNC is used (see 3GPP TS 31.102 [27]) and 
separate them into MCC and MNC; if the MNC is 2 digits then a zero shall be added at the beginning; 

2. use the MCC and MNC derived in step 1 to create the "mnc<MNC>.mcc<MCC>. 3gppnetwork.org" domain 
name; 

3. add the label "oam" to the beginning of the domain name. 
An example of an OAM System Realm/Domain is: 

IMSI in use: 234150999999999; 

Where: 

MCC = 234; 

MNC = 15; 

MSIN = 0999999999; 

Which gives the OAM System Realm/Domain name: oam.mnc015.mcc234.3gppnetwork.org. 

NOTE: If it is not possible for a Relay Node to identify whether a 2 or 3 digit MNC is used (e.g. USIM is inserted 
and the length of MNC in the IMSI is not available in the "Administrative data" data file), it is 
implementation dependent how the Relay Node determines the length of the MNC (2 or 3 digits). 
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23.3 Identifiers for Domain Name System procedures 

23.3.1 Introduction 

This clause describes Domain Name System (DNS) related identifiers used by the procedures specified in 3GPP TS 

29.303 [73]. 

23.3.2 Fully Qualified Domain Names (FQDNs) 

23.3.2.1 General 

See subclause 19.4.2.1. 

23.3.2.2 Relay Node Vendor-Specific 0AM System 

As part of the startup procedure, relay nodes (see 3GPP TS 36.300 [91], sub-clause 4.7) needs to discover its Operations 
and Maintainence (OAM) system. A relay node vendor-specific OAM system within an operator" s network is identified 
using the relay node type allocation code from IMEI or IMEISV (IMEl-TAC), MNC and MCC from IMSI and in some 
cases also tracking area code information associated to the eNB serving the relay node. 

A subdomain name for use by EUTRAN OAM system nodes shall be derived from the MNC and MCC by adding the 
label "eutran" to the beginning of the OAM System Realm/Domain (see sub-clause 23.2). 

The vendor-specific relay node OAM system FQDN shall be constructed as following: 

• tac-lb<TAC-low-byte>.tac-hb<TAC-high-byte>.imei-tac<IMEI-TAC>.eutran- 
rn.oam.mnc<MNC>.mcc<MCC>. 3gppnetwork.org 

The IMEI-TAC is 8 decimal digits (see sub-clause 6.2). 

NOTE: IMEl-TAC is used for the type allocation code from IMEI or IMEISV instead of TAC in this sub-clause 
in order to separate it from the tracking area code (TAC). 

The TAC is a 16 bit integer. <TAC-high-byte> is the hexadecimal string of the most significant byte in the TAC and 
<TAC-low-byte > is the hexadecimal string of the least significant byte. If there are less than 2 significant digits in 
<TAC-high-byte> or <TAC-low-byte >, "0" digit(s) shall be inserted at the left side to fill the 2 digit coding. 
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Annex A (informative): 
Colour Codes 

A.1 Utilization of the BSIC 

A BSIC is allocated to each cell. A BSIC can take one of 64 values. In each cell the BSIC is broadcast in each burst sent 
on the SCH, and is then known by all MSs which synchronise with this cell. The BSIC is used by the MS for several 
purposes, all aiming at avoiding ambiguity or interference which can arise when an MS in a given position can receive 
signals from two cells using the same BCCH frequency . 

Some of the uses of the BSIC relate to cases where the MS is attached to one of the cells. Other uses relate to cases 
where the MS is attached to a third cell, usually somewhere between the two cells in question. 

The first category of uses includes: 

The three least significant bits of the BSIC indicate which of the 8 training sequences is used in the bursts sent 
on the downlink common channels of the cell. Different training sequences allow for a better transmission if 
there is interference. The group of the three least significant bits of the BSIC is called the BCC (Base station 
Colour Code). 

The BSIC is used to modify the bursts sent by the MSs on the access bursts. This aims to avoid one cell correctly 
decoding access bursts sent to another cell. 

The second category of uses includes: 

When in connected mode, the MSs measure and report the level they receive on a number of frequencies, 
corresponding to the BCCH frequencies of neighbouring cells in the same network as the used cell. Along with 
the measurement result, the MS sends to the network the BSIC which it has received on that frequency. This 
enables the network to discriminate between several cells which happen to use the same BCCH frequency. Poor 
discrimination might result in faulty handovers. 

The content of the measurement report messages is limited to information for 6 neighbour cells. It is therefore 
useful to limit the reported cells to those to which handovers are accepted. For this purpose, each cell provides a 
list of the values of the three most significant bits of the BSICs which are allocated to the cells which are useful 
to consider for handovers (usually excluding cells in other PLMNs). This information enables the MS to discard 
information for cells with non-conformant BSICs and not to report them. The group of the three most significant 
bits of the BSIC is called the NCC (Network Colour Code). 

It should be noted that when in idle mode, the MS identifies a cell (for cell selection purposes) according to the cell 
identity broadcast on the BCCH and not by the BSIC. 



A.2 Guidance for planning 

From these uses, the following planning rule can be derived: 

If there exist places where MSs can receive signals from two cells, whether in the same PLMN or in different 
PLMNs, which use the same BCCH frequency, it is highly preferable that these two cells have different BSICs. 

Where the coverage areas of two PLMNs overlap, the rule above is respected if: 

1) The PLMNs use different sets of BCCH frequencies (In particular, this is the case if no frequency is common to 
the two PLMNs. This usually holds for PLMNs in the same country), or 

2) The PLMNS use different sets of NCCs, or 

3) BSIC and BCCH frequency planning is co-ordinated. 
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Recognizing that method 3) is more cumbersome than method 2), and that method 1) is too constraining, it is suggested 
that overlapping PLMNs which use a common part of the spectrum agree on different NCCs to be used in any 
overlapping areas. As an example, a preliminary NCC allocation for countries in the European region can be found in 
clause A. 3 of this annex. 

This example can be used as a basis for bilateral agreements. However, the use of the NCCs allocated in clause A.3 is 
not compulsory. PLMN operators can agree on different BSIC allocation rules in border areas. The use of BSICs is not 
constrained in non-overlapping areas, or if ambiguities are resolved by using different sets of BCCH frequencies. 



A.3 Example of PLMN Colour Codes (NCCs) for the 
European region 



Austria 

Belgium 

Cyprus 

Denmark 

Finland 

France 

Germany 

Greece 

Iceland 

Ireland 

Italy 

Liechtenstein 

Luxembourg 

Malta 

Monaco 

Netherlands 

Norway 

Portugal 

San Marino 

Spain 

Sweden 

Switzerland 

Turkey 

UK 

Vatican 

Yugoslavia 




1 

3 
1 



3 



3 

2 

2 

2 

1 

3 (possibly 0(=France)) 



3 

3 

(possibly 2(= Italy)) 
1 

2 
1 
2 
2 

1 (possibly 2(=Italy) 
3 



This allows a second operator for each country by allocating the colour codes n (in the table) and n + 4. More than 2 
colour codes per country may be used provided that in border areas only the values n and/or n+4 are used. 



£75/ 



3GPP TS 23.003 version 10.6.0 Release 10 



72 



ETSI TS 123 003 VI 0.6.0 (2013-01) 



Annex B (normative): 

IMEI Check Digit computation 

B.1 Representation of IIVIEI 

The International Mobile station Equipment Identity and Software Version number (IMEISV), as defined in clause 6, is 
a 16 digit decimal number composed of three distinct elements: 

- an 8 digit Type Allocation Code (TAG); 

- a6digit Serial Number (SNR); and 

a 2 digit Software Version Number (SVN). 
The IMEISV is formed by concatenating these three elements as illustrated below: 



TAG 


SNR 


SVN 1 



Figure A.I : Composition of the IIVIEISV 

The IMEI is complemented by a check digit as defined in clause 3. The Luhn Gheck Digit (GD) is computed on the 14 
most significant digits of the IMEISV, that is on the value obtained by ignoring the SVN digits. 

The method for computing the Luhn check is defined in Annex B of the International Standard "Identification cards - 
Numbering system and registration procedure for issuer identifiers" (ISO/IEG 7812 [3]). 

In order to specify precisely how the GD is computed for the IMEI, it is necessary to label the individual digits of the 
IMEISV, excluding the SVN. This is done as follows: 

The (14 most significant) digits of the IMEISV are labelled D14, D13 ... Dl, where: 

- TAG = D14, D13 ... D7 (with D7 the least significant digit of TAG); 

- SNR = D6, D5 ... Dl (with Dl the least significant digit of SNR). 



B.2 Computation of CD for an IIVIEI 

Gomputation of GD from the IMEI proceeds as follows: 

Step 1: Double the values of the odd labelled digits Dl, D3, D5 ... D13 of the IMEI. 

Step 2: Add together the individual digits of all the seven numbers obtained in Step 1, and then add this sum to 

the sum of all the even labelled digits D2, D4, D6 ... D14 of the IMEI. 

Step 3: If the number obtained in Step 2 ends in 0, then set GD to be 0. If the number obtained in Step 2 does not 

end in 0, then set GD to be that number subtracted from the next higher number which does end in 0. 



B.3 Example of computation 



IIVIEI (14 most significant digits): 



TAG 


SNR 


D14 


D13 


D12 


Dll DIO 


D9 


D8 


D7 


D6 


D5 


D4 D3 


D2 


Dl 


2 


6 





5 3 


1 


7 


9 


3 


1 


1 3 


8 


3 
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Step 1 : 



2 


6 





5 


3 


1 


7 


9 


3 


1 


[ 3 


8 


3 




x2 




x2 




x2 




x2 




x2 


x2 




x2 




12 




10 




2 




18 




2 


6 




6 



Step 2: 

2+1+2+0+1+0+3+2+7+1+8+3+2+1+6+8+6= 53 



Step 3: 



CD = 60 - 53 = 7 
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Annex C (normative): 
Naming convention 



This normative annex defines a naming convention which will make it possible for DNS servers to translate logical 
names for GSNs and RAs to physical IP addresses. The use of logical names is optional, but if the option is used, it 
shall comply with the naming convention described in this annex. The fully qualified domain names used throughout 
this annex shall follow the format defined in IETF RFC 1035 [19]. 



C.1 Routing Area Identities 

This subclause describes a possible way to support inter-PLMN roaming. 

When an MS roams between two SGSNs within the same PLMN, the new SGSN finds the address of the old SGSN 
from the identity of the old RA. Thus, each SGSN can determine the address of every other SGSN in the PLMN. 

When an MS roams from an SGSN in one PLMN to an SGSN in another PLMN, the new SGSN may be unable to 
determine the address of the old SGSN. Instead, the SGSN transforms the old RA information to a logical name of the 
form: 

racAAAA.lacBBBB.mncYYY.mccZZZ.gprs 

A and B shall be Hex coded digits; Y and Z shall be encoded as single digits (in the range 0-9). 

If there are less than 4 significant digits in AAAA or BBBB, one or more "0" digit(s) is/are inserted at the left side to fill 
the 4 digit coding. If there are only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digit 
coding. 

As an example, the logical name for RAC 123 A, LAC 234B, MCC 167 and MNC 92 will be coded in the DNS 
server as: 

racl23A.lac234B.mnc092.mccl67.gprs. 

The SGSN may then acquire the IP address of the old SGSN from a DNS server, using the logical address. Introducing 
the DNS concept in GPRS enables operators to use logical names instead of IP addresses when referring to nodes 
(e.g. GSNs), thus providing flexibility and transparency in addressing. Each PLMN should include at least one DNS 
server (which may optionally be connected via the DNS service provided by the GSM Association). Note that these 
DNS servers are GPRS internal entities, unknown outside the GPRS system. 

The above implies that at least MCC II MNC II LAC II RAC (= RAI) is sent as the RA parameter over the radio interface 
when an MS roams to another RA. 

If for any reason the new SGSN fails to obtain the address of the old SGSN, the new SGSN takes the same actions as 
when the corresponding event occurs within one PLMN. 

Another way to support seamless inter-PLMN roaming is to store the SGSN IP addresses in the HLR and request them 
when necessary. 

If Intra Domain Connection of RAN Nodes to Multiple CN Nodes (see 3GPP TS 23.236 [23]) is applied then the 
Network Resource Identifier (NRJ) identifies uniquely a given SGSN node out of all the SGSNs serving the same pool 
area. 

If the new SGSN is not able to extract the NRI from the old P-TMSI, it shall retrieve the address of the default SGSN 
(see 3GPP TS 23.236 [23]) serving the old RA, using the logical name described earlier in this section. The default 
SGSN in the old RA relays the GTP signalling to the old SGSN identified by the NRI in the old P-TMSI unless the 
default SGSN itself is the old SGSN. 

If the new SGSN is able to extract the NRI from the old P-TMSI, then it shall attempt to derive the address of the old 
SGSN from the NRI and the old RAI. NRI-to-SGSN assignments may be either configured (by O&M) in the new 
SGSN, or retrieved from a DNS server. If a DNS server is used, it shall be queried using the following logical name, 
derived from the old RAI and NRI information: 
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nriCCCC.racDDDD.lacEEEE.mncYYY.mccZZZ.gprs 

C, D and E shall be Hex coded digits, Y and Z shall be encoded as single digits (in the range 0-9). If there are less than 
4 significant digits in CCCC, DDDD or EEEE, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digit 
coding. If there are only 2 significant digits in YY Y, a "0" digit is inserted at the left side to fill the 3 digits coding. 

As an example, the logical name for NRI 3A, RAC 123A, LAC 234B, MCC 167 and MNC 92 will be coded in the 
DNS server as: 

nri003A.racl23A.lac234B.mnc092.mccl67.gprs. 

If for any reason the new SGSN fails to obtain the address of the old SGSN using this method, then as a fallback 
method it shall retrieve the address of the default SGSN serving the old RA. 



C.2 GPRS Support Nodes 

This subclause defines a naming convention for GSNs. 

It shall be possible to refer to a GSN by a logical name which shall then be translated into a physical IP address. This 
clause proposes a GSN naming convention which would make it possible for an internal GPRS DNS server to make the 
translation. 

An example of how a logical name of an SGSN could appear is: 
sgsnXXXX.mncYYY.mccZZZ.gprs 

X, shall be Hex coded digits, Y andZz shall be encoded as single digits (in the range 0-9). 

If there are less than 4 significant digits in XXXX one or more "0" digit(s) is/are inserted at the left side to fill the 4 
digits coding. If there are only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digit coding. 

As an example, the logical name for SGSN 1B34, MCC 167 and MNC 92 will be coded in the DNS server as: 
sgsnlB34. mnc092.mccl67.gprs 



C.3 Target ID 

This subclause describes a possible way to support SRNS relocation. 

In UMTS, when SRNS relocation is executed, a target ID which consists of MCC, MNC and RNC ID is used as 
routeing information to route to the target RNC via the new SGSN. An old SGSN shall resolve a new SGSN IP address 
by a target ID to send the Forward Relocation Request message to the new SGSN. 

It shall be possible to refer to a target ID by a logical name which shall be translated into an SGSN IP address to take 
into account inter-PLMN handover. The old SGSN transforms the target ID information into a logical name of the form: 

rncXXXX.mncYYY.mccZZZ.gprs 

X shall be Hex coded digits; Y and Z shall be encoded as single digits (in the range 0-9). If there are less than 4 
significant digits in XXXX, one or more "0" digit(s) is/are inserted at the left side to fill the 4 digits coding. If there are 
only 2 significant digits in YYY, a "0" digit is inserted at the left side to fill the 3 digit coding. Then, for example, a 
DNS server is used to translate the logical name to an SGSN IP address. 

As an example, the logical name for RNC 1B34, MCC 167 and MNC 92 will be coded in the DNS server as: 
rnclB34.mnc092.mccl67.gprs 
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Annex D (informative): 

Applicability and use of the ".3gppnetwork.org" domain 

name 

There currently exists a private IP network between operators to provide connectivity for user transparent services that 
utiHse protocols that rely on IP. This includes (but is not necessarily limited to) such services as GPRS/PS roaming, 
WLAN roaming, GPRS/PS inter-PLMN handover and inter-MMSC MM delivery. This inter-PLMN IP backbone 
network consists of indirect connections using brokers (known as GRXs - GPRS Roaming Exchanges) and direct 
inter-PLMN connections (e.g. private wire); it is however not connected to the Internet. More details can be found in 
GSMAPRDIR.34[57]. 

Within this inter-PLMN IP backbone network, the domain name ".gprs" was originally conceived as the only domain 
name to be used to enable DNS servers to translate logical names for network nodes to IP addresses (and vice versa). 
However, after feedback from the Internet Engineering Task Force (IETF) it was identified that use of this domain 
name has the following drawbacks: 

1. Leakage of DNS requests for the ".gprs" top level domain into the public Internet is inevitable at sometime or other, 
especially as the number of services (and therefore number of nodes) using the inter-PLMN IP backbone increases. 
In the worst case scenario of faulty clients, the performance of the Internet's root DNS servers would be seriously 
degraded by having to process requests for a top level domain that does not exist. 

2. It would be very difficult for network operators to detect if/when DNS requests for the ".gprs" domain were leaked 
to the public Internet (and therefore the security policies of the inter-PLMN IP backbone network were breached), 
because the Internet's root DNS servers would simply return an error message to the sender of the request only. 

To address the above, the IETF recommended using a domain name that is mutable in the pubic domain but which 
requests to it are not actually serviced in the public domain. The domain name ".3gppnetwork.org" was chosen as the 
new top level domain name to be used (as far as possible) within the inter-PLMN IP backbone network. 

Originally, only the DNS servers connected to the inter-PLMN IP backbone network were populated with the correct 
information needed to service requests for all sub-domains of this domain. However, it was later identified that some 
new services needed their allocated sub-domain(s) to be resolvable by the UE and not just inter-PLMN IP network 
nodes. To address this, additional, higher-level sub-domains were created: 

"pub.3gppnetwork.org", which is to be used for domain names that need to be resolvable by UEs (and possibly 
network nodes too) that are connected to a local area network that is connected to the Internet; and 

"ipxuni.3gppnetwork.org", which is to be used for domain names for UNI interfaces that need to be resolvable 
by UEs that are connected to a local area network that is not connected to the Internet (e.g. local area networks 
connected to the inter-PLMN IP network of the IPX). 

Therefore, DNS requests for the above domain names can be resolved, while requests for all other sub-domains of 
"3gppnetwork.org" can simply be configured to return the usual DNS error for unknown hosts (thereby avoiding 
potential extra, redundant load on the Internet's root DNS servers). 

The GSM Association is in charge of allocating new sub-domains of the ".3gppnetwork.org" domain name. The 
procedure for requesting new sub-domains can be found in Annex E. 
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Annex E (normative): 

Procedure for sub-domain allocation 

When a 3GPP member company identifies the need for a new sub-domain name of ".3gppnetwork.org", that 3GPP 
member company shall propose a CR to this specification at the earliest available meeting of the responsible working 
group for this TS. The CR shall propose a new sub-domain name. The new sub-domain proposed shall be formatted in 
one of the formats as described in the following table. 



Sub-domain Format 


Intended Usage 


<service id> .mnc<MNC> .mcc<MCC> . 3gppnetwork.org 

(see notes 1 and 2) 


Domain name that is to be resolvable by network 
nodes only. This format inherently adds protection to 
the identified node, in that attempted DNS 
resolutions instigated directly from end user 
equipment will fail indefinitely. 


<service id> .mnc<MNC> .mcc<MCC> .pub. Sgppnetwork.org 

(see notes 1 and 2) 


Domain name that is to be resolvable by UEs and/or 
network nodes. This format inherently adds global 
resolution capability, but at the expense of 
confidentiality of network topology. 


<service id> .mnc<MNC> .mcc<MCC> . ipxuni . 3gppnetwork.org 

(see notes 1 and 2) 


Domain name for UNI interface that is to be 

resolvable by UEs that are connected to an inter- 

PLMN IP network that has no connectivity to the 

Internet. 

This format inherently adds resolution capability for 

UEs in closed IP networks e.g. IPX. 



Table E.I : Sub-domain formats for the "3gppnetwork.org" domain and their respective intended 

usage 

NOTE 1: "<service_ID>" is a chosen label, conformant to DNS naming conventions (usually IETF RFC 1035 [19] 
and IETF RFC 1 123 [20]) that clearly and succinctly describe the service and/or operation that is intended 
to use this sub-domain. 

NOTE 2: "<MNC>" and "<MCC>" are the MNC (padded to the left with a zero, if only a 2-digit MNC) and MCC 
of a PLMN. 



Care should be taken when choosing which format a domain name should use. Once a format has been chosen, the 
responsible working group shall then check the CR and either endorse it or reject it. If the CR is endorsed, then the 
responsible working group shall send an LS to the GSMA IREG describing the following key points: 

the context 

the service 

intended use 

involved actors 

proposed new sub-domain name 

GSMA IREG will then verify the consistence of the proposal and its usage within the domain" s structure and 
interworking rules (e.g. access to the GRX Root DNS servers). GSMA IREG will then endorse or reject the proposal 
and inform the responsible working group (in 3GPP). It is possible that GSMA IREG will also specify, changes to the 
newly proposed sub-domain name (e.g. due to requested sub-domain name already allocated). 

It should be noted that services already defined to use the ".gprs" domain name will continue to do so and shall not use 
the new domain name of ".3gppnetwork.org"; this is to avoid destabilising services that are already live. 



£75/ 



3GPP TS 23.003 version 10.6.0 Release 10 



78 



ETSI TS 123 003 VI 0.6.0 (2013-01) 



Annex F (informative): 
Change history 
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5.5.0 
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5.7.0 


Correction to definition of Group-ID, Group call area 
ID and Group Call Reference 


CN#21 


23.003 


5.7.0 


073r2 


Rel-6 


6.0.0 
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6.1.0 


087 


Rel-6 


6.2.0 
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Clarification of the uses of SIP URIs for Public User 
ID 


CN#24 


23.003 


6.2.0 


088r1 


Rel-6 


6.3.0 
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6.4.0 
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CN#25 


23.003 


6.3.0 


091 r1 


Rel-6 


6.4.0 
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23.003 


6.4.0 


092r2 


Rel-6 


6.5.0 


'otherrealm' format of Decorated NAI 


CN#26 


23.003 


6.4.0 


095r1 


Rel-6 


6.5.0 
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23.003 


6.4.0 


096r1 


Rel-6 


6.5.0 


BSF address 


CN#27 


23.003 


6.5.0 
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Rel-6 


6.6.0 
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23.003 


6.5.0 


093r3 


Rel-6 


6.6.0 
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23.003 


6.6.0 


0099r4 
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6.7.0 


W-APN Definition 
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23.003 


6.6.0 
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6.7.0 
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Rel-6 


6.7.1 
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7.2.0 
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Rel-7 
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7.4.0 
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7.4.0 


0134r1 

0135r2 
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Rel-7 


7.5.0 
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Remove emergency APN 
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23.003 


7.5.0 
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Rel-7 


7.6.0 


Correction to text describing W-APN format 


CT#39 


23.003 


7.6.0 


0141r1 


Rel-7 


7.7.0 
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CT#39 


23.003 


7.7.0 


0140 


Rel-8 


8.0.0 


Wildcarded Public User Identities format 


CT#40 


23.003 


8.0.0 


0142r2 
0144 


Rel-8 


8.1.0 


IMS public and private identity derivation in 3GPP2 
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0223 
0225r1 
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Rel-9 9.2.0 
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Exclude prepended digit from the NAI in PMIPv6 
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Rel-9 9.3.0 


Removal of the redundancy reference to 23.401 
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9.5.0 


Correction of C-MSISDN definition 
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23.003 
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Rel-10 


10.0.0 


eNodeB-ID FQDN for DNS procedures 


Determination of type of source node during 
TAU/RAU 


Service Parameter on PGW selection for GTP 
based S2b 
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23.003 


10.0.0 


0274r3 
0279r3 
0277r1 
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0280r2 

0286 
0289 


Rel-10 


10.1.0 


Relay Node OAIVI system identification 


Correction of C-MSISDN definition 


Determination of type of source node during 
TAU/RAU 


Correction to a reference of an outdated IETF draft 
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Correction to the reserved values for Tracking Area 
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DNS Service Support For Sv 


Clarfication of decoding of NRI 
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23.003 


10.1.0 


0290 
0293r2 
0294r2 
0296r1 

0299 


Rel-10 


10.2.0 
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UE moving from E-UTRAN to GERAN 
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0282r4 
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10.3.0 
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10.3.0 


031 6r1 
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Rel-10 


10.4.0 
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CT#55 
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10.4.0 
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